Architecture d’approvisionnement d’identité d’application locale Microsoft Entra
Vue d’ensemble
Le diagramme suivant présente une vue d’ensemble du fonctionnement du provisionnement d’applications local.
Il existe trois composants principaux pour provisionner les utilisateurs dans une application locale :
- L’agent d’approvisionnement assure la connectivité entre Microsoft Entra ID et votre environnement local.
- L’hôte du connecteur ECMA (Extensible Connectivity) convertit les demandes d’approvisionnement de Microsoft Entra ID en demandes adressées à votre application cible. Il sert de passerelle entre Microsoft Entra ID et votre application. Vous pouvez l’utiliser pour importer les connecteurs ECMA2 existants utilisés avec Microsoft Identity Manager. L’hôte ECMA n’est pas obligatoire si vous avez créé une application SCIM ou une passerelle SCIM.
- Le service d’approvisionnement Microsoft Entra sert de moteur de synchronisation.
Remarque
La synchronisation de Microsoft Identity Manager n’est pas obligatoire. Toutefois, vous pouvez l’utiliser pour générer et tester votre connecteur ECMA2 avant de l’importer dans l’hôte ECMA. Le connecteur ECMA2 est spécifique à MIM, où l’hôte ECMA est spécifique pour une utilisation avec l’agent d’approvisionnement.
Configuration requise du pare-feu
Vous n’avez pas besoin d’ouvrir de connexion sortante sur le réseau d’entreprise. Les agents de provisionnement utilisent uniquement des connexions sortantes vers le service de provisionnement, ce qui signifie qu’il n’est pas nécessaire d’ouvrir des ports de pare-feu pour les connexions entrantes. Vous n’avez pas non plus besoin de réseau de périmètre (DMZ) parce que toutes les connexions sont sortantes et sur un canal sécurisé.
Les points de terminaison sortants requis pour les agents d’approvisionnement sont détaillés ici.
Architecture de l’hôte connecteur ECMA
L’hôte connecteur ECMA utilise plusieurs zones pour effectuer la configuration locale. Le diagramme ci-dessous est un dessin conceptuel qui présente ces zones individuelles. La table ci-dessous décrit les zones plus en détail.
Domaine | Description |
---|---|
Points de terminaison | Responsable de la communication et du transfert de données avec le service d’approvisionnement Microsoft Entra |
Cache en mémoire | Utilisé pour stocker les données importées à partir de la source de données locale |
Synchronisation automatique | Assure la synchronisation asynchrone des données entre l’hôte connecteur ECMA et la source de données locale |
Logique métier | Utilisé pour coordonner toutes les activités d’hôte connecteur ECMA. L’heure de synchronisation automatique est configurable dans l’hôte ECMA. Elle se trouve dans la page Propriétés. |
À propos des attributs d’ancre et des noms uniques
Les informations suivantes sont fournies pour mieux expliquer les attributs d’ancre et les noms uniques, en particulier utilisés par le connecteur genericSQL.
L’attribut d’ancrage est un attribut unique d’un type d’objet qui ne change pas et représente cet objet dans le cache mémoire hôte du connecteur ECMA.
Le nom unique (DN) est un nom qui identifie de façon unique un objet en indiquant son emplacement actuel dans la hiérarchie de répertoires. Ou avec SQL, dans la partition. Le nom est formé en concaténant l’attribut d’ancre à la racine de la partition du répertoire.
Lorsque nous considérons les DN traditionnels dans un format traditionnel, par exemple, Active Directory ou LDAP, nous pensons à quelque chose de similaire à :
CN=Lola Jacobson,CN=Users,DC=contoso,DC=com
Toutefois, pour une source de données telle que SQL, qui est plate et non hiérarchique, le DN doit être déjà présent dans l’une des tables ou créé à partir des informations que nous fournissons à l’hôte connecteur ECMA.
Cela peut être réalisé en cochant la case Autogenerated au moment de la configuration du connecteur genericSQL. Lorsque vous choisissez l’autogénération du DN, l’hôte ECMA génère un DN au format LDAP : CN=<anchorvalue>,OBJECT=<type>. Cela suppose également que la fonctionnalité Ancre soit décochée pour le DN dans la page Connectivité.
Le connecteur genericSQL s’attend à ce que le DN soit rempli à l’aide d’un format LDAP. Le connecteur SQL générique utilise le style LDAP avec le nom de composant « OBJECT = ». Cela lui permet d’utiliser des partitions (chaque type d’objet est une partition).
Puisque l’hôte connecteur ECMA ne prend actuellement en charge que le type d’objet USER, l’OBJECT=<type> sera OBJECT=USER. Le DN d’un utilisateur avec une valeur d’ancre ljacobson serait donc :
CN=ljacobson,OBJECT=USER
Workflow de création de l’utilisateur
Le service d’approvisionnement Microsoft Entra interroge l’hôte connecteur ECMA pour déterminer si l’utilisateur existe. Il utilise l’attribut correspondant comme filtre. Cet attribut est défini dans le portail Azure sous Applications d'entreprise -> Approvisionnement local -> approvisionnement -> correspondance d’attributs. Il est indiqué par le 1 pour la priorité correspondante. Vous pouvez définir un ou plusieurs attributs correspondants et les classer par ordre de priorité. Si vous souhaitez modifier l’attribut correspondant, vous pouvez également le faire.
L’hôte connecteur ECMA reçoit la requête GET et interroge son cache interne pour déterminer si l’utilisateur existe et s’il a été importé. Cette opération s’effectue à l’aide du ou des attributs correspondants ci-dessus. Lors de la configuration de plusieurs attributs correspondants, le service de provisionnement de Microsoft Entra effectue une requête GET pour chaque attribut, tandis que l’hôte ECMA recherche une correspondance dans son cache.
Si l’utilisateur n’est pas trouvé, Microsoft Entra ID envoie une requête POST pour le créer. L’hôte connecteur ECMA répond ensuite à Microsoft Entra ID avec un HTTP 201 et un identifiant utilisateur. Cet ID est dérivé de la valeur d’ancre définie dans la page Types d’objets. Cette ancre sera utilisée par Microsoft Entra ID pour interroger l’hôte connecteur ECMA pour les requêtes ultérieures et suivantes.
Si l’utilisateur est modifié dans Microsoft Entra ID, Microsoft Entra ID effectue une requête GET pour récupérer l’utilisateur en utilisant l’ancre de l’étape précédente, plutôt que l’attribut correspondant de l’étape 1. Cela permet, par exemple, de modifier l’UPN sans rompre le lien entre l’utilisateur dans Microsoft Entra ID et dans l’application.
Bonnes pratiques concernant l’agent
- L’utilisation du même agent pour la fonctionnalité de provisionnement local avec Workday / SuccessFactors / Synchronisation Cloud Microsoft Entra Connect n’est pas prise en charge pour le moment. Nous travaillons activement à la prise en charge du provisionnement local sur le même agent que les autres scénarios d’approvisionnement.
-
- Évitez toute forme d’inspection inline sur les communications TLS sortantes établies entre les agents et Azure. Ce type d’inspection inline entraîne une dégradation du flux de communication.
- L’agent doit communiquer avec Azure et votre application, donc le placement de l’agent affecte la latence de ces deux connexions. Vous pouvez réduire la latence du trafic de bout en bout en optimisant chaque connexion réseau. Chaque connexion peut être optimisée en :
- Réduisant la distance entre les deux extrémités du tronçon.
- Choisissant le réseau approprié à parcourir. Par exemple, parcourir un réseau privé au lieu de l’Internet public peut être plus rapide en raison des liaisons dédiées.
- L’agent et l’hôte ECMA s’appuient sur un certificat pour la communication. Le certificat auto-signé généré par l’hôte ECMA ne doit être utilisé qu’à des fins de test. Le certificat auto-signé expire dans deux ans par défaut et ne peut pas être révoqué. Microsoft recommande d’utiliser un certificat provenant d’une autorité de certification approuvée pour les cas d’usage de production.
Haute disponibilité
Les informations suivantes s’appliquent aux scénarios de haute disponibilité/basculement.
Pour les applications locales utilisant le connecteur ECMA, la recommandation consiste à mettre en œuvre un agent actif et un agent passif (configurés, mais arrêtés et non affectés à l’application d’entreprise dans Entra) par centre de données.
Lorsque vous effectuez un basculement, il est recommandé d’effectuer les opérations suivantes :
- Arrêtez l’agent actif (A).
- Annulez l’affectation de l’agent A à partir de l’application d’entreprise.
- Redémarrez l’agent passif (B).
- Affectez l’agent B à l’application d’entreprise.
Pour les applications locales utilisant le connecteur SCIM, la recommandation consiste à mettre en œuvre deux agents actifs par application.
Questions relatives à l'agent d'approvisionnement
Certaines questions courantes sont traitées ici.
Comment connaître la version de mon agent d'approvisionnement ?
- Connectez-vous au serveur Windows sur lequel l’agent d’approvisionnement est installé.
- Accédez à Panneau de configuration>Désinstaller ou modifier un programme.
- Recherchez la version correspondant à l'entrée Agent d'approvisionnement Microsoft Entra Connect.
Est-ce que je peux installer l’agent de provisionnement sur le même serveur qui exécute Microsoft Entra Connect ou Microsoft Identity Manager ?
Oui. Vous pouvez installer l’agent de provisionnement sur le même serveur qui exécute Microsoft Entra Connect ou Microsoft Identity Manager, mais ils ne sont pas requis.
Comment configurer l'agent d'approvisionnement afin qu'il utilise un serveur proxy pour la communication HTTP sortante ?
L'agent d'approvisionnement prend en charge l'utilisation du proxy sortant. Vous pouvez le configurer en modifiant le fichier de configuration C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config de l'agent. Ajoutez les lignes suivantes à la fin du fichier, juste avant la balise </configuration>
de fermeture. Remplacez les variables [proxy-server]
et [proxy-port]
par le nom de votre serveur proxy et les valeurs de port.
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
usesystemdefault="true"
proxyaddress="http://[proxy-server]:[proxy-port]"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
Comment puis je m’assurer que l'agent d'approvisionnement peut communiquer avec le locataire Microsoft Entra et qu'aucun pare-feu ne bloque les ports requis par l'agent ?
Vous pouvez également vérifier si tous les ports requis sont ouverts.
Comment désinstaller l'agent d'approvisionnement ?
- Connectez-vous au serveur Windows sur lequel l’agent d’approvisionnement est installé.
- Accédez à Panneau de configuration>Désinstaller ou modifier un programme.
- Désinstallez les programmes suivants :
- Agent d’approvisionnement Microsoft Entra Connect
- Microsoft Entra Connect Agent Updater
- Package de l’agent d’approvisionnement Microsoft Entra Connect
Historique de l’agent de provisionnement
Cet article répertorie les versions et les fonctionnalités de l’agent d’approvisionnement Microsoft Entra Connect qui ont été publiées. L’équipe Microsoft Entra met régulièrement à jour l’agent d’approvisionnement avec de nouvelles fonctions et fonctionnalités. Veillez à ne pas utiliser le même agent pour l’approvisionnement local et pour la synchronisation avec le cloud / le provisionnement basé sur les ressources humaines.
Microsoft offre une prise en charge directe de la version la plus récente de l’agent et de la version précédente.
Télécharger le lien
L’approvisionnement d’applications locales a été intégré dans l’agent d’approvisionnement et est disponible à partir du portail. Consultez Installation de l’agent d’approvisionnement.
1.1.892.0
20 mai 2022 - publiée pour téléchargement
Problèmes résolus
- Nous avons ajouté la prise en charge de l’exportation de modifications vers des attributs entiers, ce qui bénéficie aux clients utilisant le connecteur LDAP générique.
1.1.846.0
11 avril 2022 - publié pour téléchargement
Problèmes résolus
- Nous avons ajouté la prise en charge d’ObjectGUID comme ancre pour le connecteur LDAP générique lors du provisionnement d’utilisateurs dans AD LDS.