Microsoft Entra Connect Sync : Comprendre le provisionnement déclaratif

Cet article explique le modèle de configuration dans Microsoft Entra Connect. Le modèle est appelé Provisionnement déclaratif et vous permet de modifier facilement la configuration. De nombreuses choses décrites dans cet article sont avancées et ne sont pas requises pour la plupart des scénarios clients.

Aperçu

L’approvisionnement déclaratif traite les objets provenant d’un répertoire connecté source. Elle détermine la façon dont l’objet et les attributs doivent être transformés d’une source à une cible. Un objet est traité dans un pipeline de synchronisation et le pipeline est le même pour les règles entrantes et sortantes. Une règle de trafic entrant provient d’un espace connecteur vers le métaverse, et une règle de trafic sortant provient du métaverse vers un espace connecteur.

Le pipeline a plusieurs modules différents. Chacun d’eux est responsable d’un concept dans la synchronisation d’objets.

• Source, 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
• Transformer, calcule la façon dont les attributs doivent être transformés et circuler
• Precedence, résout les contributions d’attribut conflictuelles
• Cible, l'objet cible

Portée

Le module d’étendue évalue un objet et détermine les règles qui se trouvent dans l’étendue et qui doivent être incluses dans le traitement. Selon les valeurs d'attributs de l'objet, différentes règles de synchronisation sont évaluées comme applicables. Par exemple, un utilisateur désactivé sans boîte aux lettres Exchange n’a pas de règles différentes de celles d’un utilisateur activé avec une boîte aux lettres.

L’étendue est définie en tant que groupes et clauses. Les clauses se trouvent à l’intérieur d’un groupe. Un AND logique est utilisé entre toutes les clauses d’un groupe. Par exemple, (département = IT ET pays = Danemark). Un OU logique est utilisé entre les groupes.

d’étendue
La portée de cette image doit être lue comme (department = IT ET country = Danemark) OU (country = Suède). Si le groupe 1 ou le groupe 2 est évalué à vrai, la règle est applicable.

Le module de portée 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 peut être trouvée quelque part dans la valeur de l’attribut.
STARTSWITH, NOTSTARTSWITH	Comparaison de chaînes qui évalue si la valeur se trouve au début de la valeur dans l’attribut.
ENDSWITH, NOTENDSWITH	Comparaison de chaînes qui évalue si la valeur se trouve à la fin de la valeur dans 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 nul, la règle s'applique.
ISIN, ISNOTIN	Évalue si la valeur est présente dans l’attribut défini. Cette opération est la variante à valeurs multiples d’EQUAL et DE 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. Par exemple, vous pouvez l’utiliser 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 applicable.

Unir

Le module de jointure dans le pipeline de synchronisation est responsable de la recherche de la relation entre l’objet dans 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.
Jointure
L’objectif est de voir s’il existe déjà un objet dans le métaverse, créé par un autre connecteur, auquel il doit être associé. 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. Dans un groupe, vous avez des clauses. Un AND logique est utilisé entre toutes les clauses d’un groupe. Un OU logique est utilisé entre les groupes. Les groupes sont traités dans l’ordre de haut en bas. Lorsqu’un groupe trouve exactement une correspondance avec un objet dans la cible, aucune autre règle de jointure n’est évaluée. Si zéro ou plusieurs objets sont trouvés, le traitement passe au groupe de règles suivant. Pour cette raison, les règles doivent être créées dans l'ordre des plus explicites en premier et les plus floues à la fin.

Les jointures de cette image sont traitées de haut en bas. Tout d’abord, le pipeline de synchronisation voit s’il existe une correspondance sur employeeID. Si ce n’est pas le cas, la deuxième règle voit 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 sont évaluées et qu’il n’existe pas exactement une correspondance, le type de lien est utilisé sur la page Description . Si cette option est définie sur Provision, un nouvel objet est créé dans la cible.

Un objet ne doit avoir qu’une seule règle de synchronisation avec des règles de jointure dans le périmètre. S’il existe plusieurs règles de synchronisation où la jointure est définie, une erreur se produit. La priorité n’est pas utilisée pour résoudre les conflits de jointure. Un objet doit avoir une règle de jointure dans son champ d'application pour que les attributs circulent avec la même direction entrante/sortante. Si vous avez besoin de flux d’attributs entrants et sortants vers le même objet, vous devez disposer à la fois d’une règle de synchronisation entrante et sortante avec jointure.

La jointure sortante a un comportement spécial lorsqu’elle tente de provisionner un objet dans un espace de connecteur cible. L’attribut DN est utilisé pour commencer par essayer une jointure inversée. S’il existe déjà un objet dans l’espace connecteur cible avec le même nom de domaine, les objets sont joints.

Le module de jointure n’est évalué qu’une seule fois lorsqu’une nouvelle règle de synchronisation entre dans l’étendue. Lorsqu’un objet est joint, il n’est pas disjoint même si les critères de jointure ne sont plus satisfaits. Si vous souhaitez disjoindre un objet, la règle de synchronisation qui a joint les objets ne doit plus être applicable.

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. Un StickyJoin est utilisé lorsqu’un connecteur n’est pas autorisé à approvisionner un nouvel objet dans le métaverse. Toutefois, lorsqu’elle est jointe, elle doit être supprimée dans la source avant la suppression de l’objet 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 la façon dont les attributs doivent passer de la source à la cible. Les flux peuvent avoir l’un des types de flux suivants: Direct, Constant ou Expression. Un flux direct, circule une valeur d’attribut as-is sans transformations supplémentaires. Une valeur constante définit la valeur spécifiée. Une expression utilise le langage d’expression d’approvisionnement déclaratif pour exprimer la façon dont la transformation doit être. Vous trouverez les détails du langage d'expression dans l'article comprendre le langage d'expression d'approvisionnement déclaratif.

La case Appliquer une fois définit que l’attribut ne doit être défini que lorsque l’objet est créé initialement. Par exemple, cette configuration peut être utilisée pour définir un mot de passe initial pour un nouvel objet utilisateur.

Fusion des valeurs d’attribut

Dans les flux d’attributs, il existe un paramètre pour déterminer si les attributs à valeurs multiples doivent être fusionnés à partir de plusieurs connecteurs différents. La valeur par défaut est Update, ce qui indique que la règle de synchronisation avec la priorité la plus élevée doit gagner.

Il existe également une option Fusionner et MergeCaseInsensitive (Fusion non sensible à la casse). Ces options vous permettent de fusionner des valeurs provenant de différentes sources. Par exemple, il peut être utilisé pour fusionner l’attribut proxyAddresses à partir 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 recevez une erreur.

La différence entre Merge et MergeCaseInsensitive réside dans la manière de traiter les valeurs d’attribut dupliquées. Le moteur de synchronisation garantit que les valeurs dupliquées ne sont pas insérées 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 devez pas voir « 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 à Mise à 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 métaverse, la priorité est utilisée pour déterminer le gagnant. La règle de synchronisation avec la priorité la plus élevée (valeur numérique la plus faible) va contribuer à la valeur. La même chose s'applique aux règles de trafic sortant. La règle de synchronisation avec la priorité la plus élevée gagne et contribue à la valeur du répertoire connecté.

Dans certains cas, au lieu de contribuer à une valeur, la règle de synchronisation doit déterminer comment d’autres règles doivent se comporter. Certains littéraux spéciaux sont utilisés pour 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 priorité inférieure peut contribuer à une valeur. Si aucune règle n’a contribué à une valeur, l’attribut métaverse est supprimé. Pour une règle de trafic sortant, si NULL est la valeur finale une fois que toutes les règles de synchronisation sont traitées, la valeur est supprimée dans le répertoire connecté.

Le littéral AuthoritativeNull est similaire à NULL, mais avec la différence qu’aucune règle de préséance inférieure ne peut contribuer à une valeur.

Un flux d’attributs peut également utiliser ignoreThisFlow. Il est similaire à NULL dans le sens où il indique qu’il n’y a rien à contribuer. La différence est qu’elle ne supprime pas une valeur déjà existante dans la cible. C'est comme si le flux d'attributs n'avait jamais existé.

Voici un exemple :

Dans Out to AD - User Exchange hybrid le flux suivant se trouve :
IIF([cloudSOAExchMailbox] = True,[cloudMSExchSafeSendersHash],IgnoreThisFlow)
Cette expression doit être lue comme suit : si la boîte aux lettres utilisateur se trouve dans l’ID Microsoft Entra, passez l’attribut de l’ID Microsoft Entra à Active Directory. Si ce n'est pas le cas, ne transférez rien vers 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 de l’attribut doit être placé entre guillemets plutôt que entre crochets :

ImportedValue("proxyAddresses").

La synchronisation entrante suppose qu’un attribut qui n’a pas atteint un répertoire connecté finira par l’atteindre à un moment donné. Par conséquent, normalement, la synchronisation obtient une valeur d’attribut à partir de l’espace connecteur respectif. Cela est vrai même s’il n’a pas encore été exporté ou si une erreur s’est produite lors de l’exportation. Toutefois, il est important de synchroniser uniquement une valeur qui a été exportée et confirmée lors de l’importation à partir du répertoire connecté. Cette fonction se trouve dans plusieurs règles de transformation prêtes à l’emploi « In From AD/AAD », où l’attribut ne doit être synchronisé que quand il a été confirmé que la valeur a été exportée avec succès.

Vous trouverez un exemple de cette fonction dans la règle de synchronisation par défaut In from AD – User Common from Exchange, pour le flux d’attribut ProxyAddresses avec Hybrid Exchange. Par exemple, lorsque proxyAddresses d’un utilisateur est ajouté, la fonction ImportedValue retourne uniquement la nouvelle valeur après avoir été confirmée à partir de l’étape d’importation suivante :

proxyAddresses<- RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))

Cette fonction est requise lorsque le répertoire cible peut modifier ou ignorer une valeur d’attribut exportée en mode silencieux, et nous voulons que la synchronisation traite uniquement les valeurs d’attribut confirmées.

Préséance

Lorsque plusieurs règles de synchronisation tentent de contribuer à la même valeur d’attribut à la cible, la valeur de précédence est utilisée pour déterminer le gagnant. La règle ayant la priorité la plus élevée (la valeur numérique la plus basse) transmettra l’attribut.

Ce classement peut être utilisé pour définir des flux d’attributs plus précis 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 priorité peut être définie entre les connecteurs. Cela permet aux connecteurs disposant de meilleures données de fournir d'abord des contributions de valeur.

Plusieurs objets à partir du même espace de connecteur

Il n’est pas possible d’avoir plusieurs objets dans le même espace de connecteur joint au même objet métaverse. Cette configuration est signalée comme ambiguë même si les attributs de la source ont la même valeur.

É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.
• Découvrez comment apporter une modification pratique à l’aide du provisionnement déclaratif dans Comment apporter une modification à la configuration par défaut.
• Continuez à lire comment les utilisateurs et les contacts fonctionnent ensemble dans Understanding Users and Contacts.

aperçu des rubriques

• Microsoft Entra Connect Sync : comprendre et personnaliser la synchronisation
• Intégration de vos identités locales à Microsoft Entra ID

rubriques de référence

• Microsoft Entra Connect Sync : Informations de référence sur les fonctions