Configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP

Article
12/13/2024

La documentation suivante fournit des informations de configuration et des tutoriels montrant comment provisionner des utilisateurs à partir de Microsoft Entra ID dans un annuaire LDAP.

Ce document décrit les étapes à suivre pour attribuer et désattribuer automatiquement des utilisateurs de Microsoft Entra ID dans un répertoire LDAP. Le document montre comment provisionner des utilisateurs dans AD LDS en prenant l’exemple d’un annuaire LDAP, mais vous pouvez aussi faire ce provisionnement dans tous les serveurs d’annuaire LDAP pris en charge mentionnés dans les sections suivantes. L’approvisionnement d’utilisateurs dans Active Directory Domain Services via cette solution n’est pas prise en charge.

Pour découvrir les informations importantes sur ce service, son fonctionnement et les questions fréquentes (FAQ), consultez Automatiser l’attribution et l’annulation de l’attribution des utilisateurs dans les applications SaaS avec Microsoft Entra ID et Architecture d’attribution d’applications locale. La vidéo suivante fournit une vue d’ensemble du provisionnement local.

Conditions préalables pour l’approvisionnement d’utilisateurs dans un répertoire LDAP

Conditions préalables locales

Une application qui utilise un serveur d’annuaire pour interroger les utilisateurs.
Un annuaire cible, autre qu’Active Directory Domain Services, où les utilisateurs peuvent être créés, mis à jour et supprimés. Par exemple, Active Directory Lightweight Services (AD LDS). Cette instance d’annuaire ne doit pas être un annuaire également utilisé pour attribuer des utilisateurs dans Microsoft Entra ID parce qu’avoir les deux scénarios peut créer une boucle avec Microsoft Entra Connect.
Ordinateur avec au moins 3 Go de RAM pour héberger un agent d’approvisionnement. L’ordinateur doit avoir Windows Server 2016 ou une version ultérieure de Windows Server, avec une connectivité à l’annuaire cible et une connectivité sortante à login.microsoftonline.com et d’autres services en ligne Microsoft et domaines Azure. Par exemple, une machine virtuelle Windows Server 2016 hébergée dans Azure IaaS ou derrière un proxy.
.NET Framework 4.7.2 doit être installé.
Facultatif : bien que cela ne soit pas obligatoire, il est recommandé de télécharger Microsoft Edge pour Windows Server et de l’utiliser à la place d’Internet Explorer.

Serveurs d’annuaire LDAP pris en charge

Le connecteur utilise diverses techniques pour détecter et identifier le serveur LDAP. Le connecteur utilise la DSE racine pour trouver le nom du fournisseur et la version, et il recherche dans le schéma des objets et attributs uniques connus pour exister dans certains serveurs LDAP.

OpenLDAP
Microsoft Active Directory Lightweight Directory Services
Serveur d’annuaire 389
Apache Directory Server
IBM Tivoli DS
Isode Directory
NetIQ eDirectory
Novell eDirectory
Open DJ
Open DS
Oracle (précédemment Sun ONE) Directory Server Enterprise Edition
RadiantOne Virtual Directory Server (VDS)

Pour plus d’informations, consultez la référence du connecteur LDAP générique.

Conditions préalables requises du cloud

Un locataire Microsoft Entra avec Microsoft Entra ID P1 ou Premium P2 (ou EMS E3 ou E5).

L’utilisation de cette fonctionnalité nécessite des licences Microsoft Entra ID P1. Pour trouver la licence adaptée à vos besoins, consultez Comparer les fonctionnalités en disponibilité générale de Microsoft Entra ID.
Rôle Administrateur d’identité hybride pour la configuration de l’agent de provisionnement et rôles Administrateur d’application ou Administrateur d’application cloud pour la configuration du provisionnement dans le portail Azure.
Les utilisateurs Microsoft Entra à attribuer dans l’annuaire LDAP doivent déjà être configurés avec les attributs qui seront requis par le schéma du serveur d’annuaire et qui sont propres à chaque utilisateur. Par exemple, il est possible que le serveur d’annuaire impose que chaque utilisateur soit associé à un numéro d’ID utilisateur unique compris entre 10000 et 30000 pour autoriser une charge de travail POSIX. Dans ce cas, vous devrez soit générer cet ID à partir d’un attribut existant de l’utilisateur, soit étendre le schéma Microsoft Entra et définir cet attribut pour les utilisateurs qui se trouvent dans l’étendue de l’application basée sur LDAP. Consultez Extensibilité Graph pour découvrir comment créer des extensions d’annuaire supplémentaires.

Plus de recommandations et restrictions

Les points suivants sont des recommandations et des restrictions supplémentaires.

Il n’est pas recommandé d’utiliser le même agent pour la synchronisation cloud et l’approvisionnement des applications locales. Microsoft recommande d’utiliser un agent distinct pour la synchronisation du cloud et un autre pour l’approvisionnement des applications locales.
Actuellement, pour les AD LDS, les utilisateurs ne peuvent pas être approvisionnés avec des mots de passe. Vous devez donc désactiver la stratégie de mot de passe pour AD LDS ou approvisionner les utilisateurs dans un état désactivé.
Pour d’autres serveurs d’annuaire, un mot de passe aléatoire initial peut être défini, mais il n’est pas possible d’approvisionner le mot de passe d’un utilisateur Microsoft Entra sur un serveur d’annuaire.
L’approvisionnement d’utilisateurs à partir de Microsoft Entra ID vers Active Directory Domain Services n’est pas pris en charge.
L’approvisionnement d’utilisateurs de LDAP vers Microsoft Entra ID n’est pas pris en charge.
L’approvisionnement d’appartenances de groupes et d’utilisateurs sur un serveur d’annuaire n’est pas pris en charge.

Sélection des profils d’exécution

Quand vous créez la configuration du connecteur définissant son interaction avec un serveur d’annuaire, vous configurez d’abord l’hôte pour qu’il lise le schéma de votre annuaire, puis vous mappez ce schéma avec celui de Microsoft Entra ID et enfin, vous configurez l’approche à suivre en continu par le connecteur, tout cela avec des profils d’exécution. Chaque profil d’exécution que vous allez configurer spécifie la façon dont le connecteur génère des demandes LDAP pour importer ou exporter des données à partir du serveur d’annuaire. Avant de déployer le connecteur sur un serveur d’annuaire existant, vous devez déterminer, avec l’opérateur de serveur d’annuaire de votre organisation, le modèle des opérations qui sera suivi avec son serveur d’annuaire.

Après la configuration, quand le service de provisionnement démarre, il effectue automatiquement les interactions configurées dans le profil d’exécution Importation complète. Dans ce profil d’exécution, le connecteur lit tous les enregistrements des utilisateurs de l’annuaire, par une opération de recherche LDAP. Ce profil d’exécution sera nécessaire ultérieurement si Microsoft Entra ID doit apporter un changement à un utilisateur. En effet, Microsoft Entra ID saura alors qu’il doit mettre à jour un objet existant pour cet utilisateur dans l’annuaire, au lieu de créer un nouvel objet pour cet utilisateur.
À chaque changement dans Microsoft Entra ID, par exemple pour attribuer un nouvel utilisateur à l’application ou mettre à jour un utilisateur existant, le service d’attribution effectue les interactions LDAP dans le profil d’exécution Exportation. Dans le profil d’exécution Exporter, Microsoft Entra ID émet des requêtes LDAP pour les objets Ajouter, Modifier, Supprimer ou Renommer dans l’annuaire, afin de synchroniser le contenu de l’annuaire avec Microsoft Entra ID.
Si votre annuaire prend en charge cette fonctionnalité, vous avez également l’option de configurer un profil d’exécution Importation d’écart. Dans ce profil d’exécution, Microsoft Entra ID lit les changements ayant été apportés dans l’annuaire, autres que par Microsoft Entra ID, depuis la dernière importation complète ou différentielle. Ce profil d’exécution est facultatif, car l’annuaire n’a peut-être pas été configuré pour prendre en charge une importation delta. Par exemple, si votre organisation utilise OpenLDAP, OpenLDAP doit avoir été déployé avec la fonctionnalité de superposition du journal d’accès activée.

Identification des interactions entre le connecteur LDAP Microsoft Entra ID et le serveur d’annuaire

Avant de déployer le connecteur sur un serveur d’annuaire existant, vous devez déterminer, avec l’opérateur de serveur d’annuaire de votre organisation, comme l’intégrer à son serveur d’annuaire. Vous allez collecter différentes informations : des informations réseau sur la connexion au serveur d’annuaire, l’authentification du connecteur auprès du serveur d’annuaire, le schéma sélectionné par le serveur d’annuaire pour modéliser les utilisateurs, le nom distinctif de base et les règles de hiérarchie d’annuaire du contexte d’affectation de noms, l’association des utilisateurs du serveur d’annuaire aux utilisateurs de Microsoft Entra ID et le comportement attendu lorsqu’un utilisateur sort de l’étendue de Microsoft Entra ID. Le déploiement de ce connecteur peut impliquer des modifications de la configuration du serveur d’annuaire, ainsi que des modifications de configuration de Microsoft Entra ID. Dans le cas de déploiements impliquant l’intégration de Microsoft Entra ID à un serveur d’annuaire tiers dans un environnement de production, nous recommandons à nos clients de se rapprocher de leur fournisseur de serveur d’annuaire ou d’un partenaire de déploiement pour obtenir de l’aide, des conseils et une assistance à l’intégration. Cet article utilise les exemples de valeurs suivants pour deux annuaires, pour AD LDS et pour OpenLDAP.

Paramètre de configuration	Emplacement où la valeur est définie	Valeur d'exemple
Nom d’hôte du serveur d’annuaire	Page Connectivité de l’Assistant Configuration	`APP3`
Numéro de port du serveur d’annuaire	Page Connectivité de l’Assistant Configuration	636. Pour LDAP sur SSL ou TLS (LDAPS), utilisez le port 636. Pour `Start TLS`, utilisez le port 389.
Compte permettant au connecteur de s’identifier sur le serveur d’annuaire	Page Connectivité de l’Assistant Configuration	`CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab` pour AD LDS et `cn=admin,dc=contoso,dc=lab` pour OpenLDAP
Mot de passe permettant au connecteur de s’authentifier auprès du serveur d’annuaire	Page Connectivité de l’Assistant Configuration
Classe d’objet structurelle pour un utilisateur dans le serveur d’annuaire	Page Types d’objets de l’Assistant Configuration	`User` pour AD LDS et `inetOrgPerson` pour OpenLDAP
Classes d’objets auxiliaires pour un utilisateur dans le serveur d’annuaire	Mappages d’attributs de la page Approvisionnement du Portail Azure	Pour OpenLDAP avec le schéma POSIX, `posixAccount` et `shadowAccount`
Attributs à remplir sur un nouvel utilisateur	Page Sélectionner les attributs de l’Assistant Configuration et mappages d’attributs de la page Approvisionnement du Portail Azure	`msDS-UserAccountDisabled`, `userPrincipalName`, `displayName` pour AD LDS et `cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword` pour OpenLDAP
Hiérarchie de noms requise par le serveur d’annuaire	Mappages d’attributs de la page Approvisionnement du Portail Azure	Définissez le nom de domaine d’un utilisateur nouvellement créé pour qu’il soit immédiatement sous `CN=CloudUsers,CN=App,DC=Contoso,DC=lab` pour AD LDS, et `DC=Contoso,DC=lab` pour OpenLDAP
Attributs pour la corrélation des utilisateurs entre Microsoft Entra ID et le serveur d’annuaire	Mappages d’attributs de la page Approvisionnement du Portail Azure	Pour AD LDS, non configuré vu que cet exemple est pour un annuaire initialement vide, et pour OpenLDAP, `mail`
Comportement de désattribution lorsqu’un utilisateur sort de l’étendue de Microsoft Entra ID	Page Déprovisionnement de l’Assistant Configuration	Suppression de l’utilisateur du serveur d’annuaire

L’adresse réseau d’un serveur d’annuaire est constituée d’un nom d’hôte et d’un numéro de port TCP, généralement 389 ou 636. Sauf si le serveur d’annuaire est colocalisé sur le même serveur Windows que le connecteur ou si vous utilisez la sécurité au niveau du réseau, les connexions réseau à un serveur d’annuaire à partir du connecteur doivent être protégées avec le protocole SSL ou TLS. Le connecteur prend en charge la connexion à un serveur d’annuaire sur le port 389 et la commande StartTLS pour activer le protocole TLS dans la session. Il accepte également la connexion à un serveur d’annuaire sur le port 636 pour LDAPS (LDAP sur TLS).

Vous devez disposer d’un compte identifié pour que le connecteur s’authentifie auprès du serveur d’annuaire déjà configuré sur le serveur d’annuaire. Ce compte est généralement identifié par un nom unique et associé à un mot de passe ou à un certificat client. Le compte de connecteur doit disposer d’autorisations suffisantes dans le modèle de contrôle d’accès de l’annuaire pour effectuer des opérations d’importation et d’exportation d’objets dans l’annuaire connecté. Le connecteur doit avoir des autorisations d’écriture pour pouvoir exporter, et des autorisations de lecture pour pouvoir importer. La configuration d’autorisation est exécutée au sein des expériences de gestion sur le répertoire cible lui-même.

Un schéma d’annuaire spécifie les classes d’objets et les attributs qui représentent une entité réelle dans l’annuaire. Le connecteur prend en charge un utilisateur représenté avec une classe d’objet structurelle (par exemple inetOrgPerson), et éventuellement des classes d’objets auxiliaires supplémentaires. Pour que le connecteur puisse approvisionner des utilisateurs dans le serveur d’annuaire, au moment de la configuration dans le portail Azure, vous définirez les mappages entre le schéma Microsoft Entra et tous les attributs obligatoires. Cela inclut les attributs obligatoires de la classe d’objets structurelle et les superclasses de cette classe, ainsi que les attributs obligatoires de toutes les classes d’objets auxiliaires. De plus, vous définirez probablement les mappages vers certains des attributs facultatifs de ces classes. Par exemple, un serveur d’annuaire OpenLDAP peut avoir besoin qu’un objet pour un nouvel utilisateur ait des attributs similaires à ceux de l’exemple suivant.

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

Les règles de hiérarchie d’annuaire implémentées par un serveur d’annuaire décrivent la façon dont les objets de chaque utilisateur sont liés les uns aux autres et aux objets existants de l’annuaire. Dans la plupart des déploiements, l’organisation choisit de définir dans son serveur d’annuaire une hiérarchie plate dans laquelle chaque objet d’un utilisateur se trouve juste au-dessous d’un objet de base commun. Supposons par exemple que le nom distinctif de base soit dc=contoso,dc=com dans le contexte de nommage d’un serveur d’annuaire : un nouvel utilisateur possédera alors un nom unique du type cn=alice,dc=contoso,dc=com. Toutefois, certaines organisations possèdent une hiérarchie d’annuaire plus complexe, auquel cas vous devrez implémenter les règles au moment de spécifier le mappage de noms uniques pour le connecteur. Par exemple, un serveur d’annuaire peut exiger que les utilisateurs se trouvent dans des unités d’organisation par service. Le nom unique d’un nouvel utilisateur se présente alors sous la forme cn=alice,ou=London,dc=contoso,dc=com. Étant donné que le connecteur ne crée pas d’objets intermédiaires pour les unités d’organisation, tous les objets intermédiaires attendus par la hiérarchie des règles du serveur d’annuaire doivent déjà exister dans le serveur d’annuaire.

Ensuite, vous devez définir les règles spécifiant la façon dont le connecteur doit déterminer s’il existe déjà un utilisateur dans le serveur d’annuaire correspondant à un utilisateur Microsoft Entra. Chaque annuaire LDAP possède un nom unique propre à chaque objet du serveur d’annuaire, mais ce nom est souvent absent pour les utilisateurs de Microsoft Entra ID. Une organisation peut proposer, dans son schéma de serveur d’annuaire, un autre attribut (par exemple mail ou employeeId) qui est également présent sur ses utilisateurs dans Microsoft Entra ID. Le connecteur peut alors, lorsqu’il approvisionne un nouvel utilisateur dans un serveur d’annuaire, rechercher s’il existe déjà dans cet annuaire un utilisateur présentant une valeur spécifique de cet attribut, et créer un utilisateur uniquement en l’absence d’un tel utilisateur.

Si votre scénario implique la création d’utilisateurs dans l’annuaire LDAP, et pas seulement la mise à jour ou la suppression d’utilisateurs existants, vous devez également déterminer comment les applications qui utilisent ce serveur d’annuaire vont gérer l’authentification. L’approche recommandée consiste à ce que les applications utilisent un protocole de fédération ou d’authentification unique tel que SAML, OAuth ou OpenID Connect pour s’authentifier auprès de Microsoft Entra ID, et s’appuient uniquement sur le serveur d’annuaire pour les attributs. Normalement, les annuaires LDAP peuvent être utilisés par les applications pour authentifier les utilisateurs en vérifiant un mot de passe, mais ce cas d’usage n’est pas possible pour l’authentification multifacteur ou lorsque l’utilisateur a déjà été authentifié. Certaines applications peuvent interroger la clé publique SSH ou le certificat de l’utilisateur à partir de l’annuaire, ce qui peut convenir pour les utilisateurs qui ont déjà les informations d’identification de ces formulaires. Toutefois, si votre application qui s’appuie sur le serveur d’annuaire ne prend pas en charge les protocoles d’authentification modernes ou des informations d’identification plus fortes, vous devrez définir un mot de passe spécifique à l’application lors de la création d’un nouvel utilisateur dans l’annuaire, car Microsoft Entra ID ne prend pas en charge l’attribution du mot de passe Microsoft Entra de l’utilisateur.

Enfin, vous devez vous mettre d’accord sur le comportement de déprovisionnement. Une fois que le connecteur est configuré et que Microsoft Entra ID a établi un lien entre un utilisateur de Microsoft Entra ID et un enregistrement de l’annuaire (soit pour un utilisateur déjà présent dans l’annuaire soit pour un nouvel utilisateur), Microsoft Entra ID peut attribuer des modifications de l’attribut de l’utilisateur Microsoft Entra ID vers l’annuaire. Si un utilisateur affecté à l’application est supprimé dans Microsoft Entra ID, alors Microsoft Entra ID envoie une opération de suppression au serveur d’annuaire. Vous pouvez également souhaiter que Microsoft Entra ID mette à jour l’objet sur le serveur d’annuaire quand un utilisateur n’est plus dans l’étendue d’utilisation de l’application. Ce comportement dépend de l’application qui utilisera le serveur d’annuaire, car beaucoup d’annuaires, parmi lesquels OpenLDAP, n’ont pas toujours de moyen par défaut d’indiquer que le compte d’un utilisateur est inactif.

Préparer l’annuaire LDAP

Si vous ne disposez pas déjà d’un serveur d’annuaire et que vous souhaitez essayer cette fonctionnalité, créez un environnement AD LDS de test en effectuant les étapes décrites dans Préparer Active Directory Lightweight Directory Services pour le provisionnement à partir de Microsoft Entra ID. Si vous avez déjà déployé un autre serveur d’annuaire, vous pouvez ignorer cet article, et passer aux étapes pour installer et configurer l’hôte du connecteur ECMA.

Installer et configurer l’agent d’attribution Microsoft Entra Connect

Si vous avez déjà téléchargé l’agent de provisionnement et que vous l’avez configuré pour une autre application locale, passez directement à la section suivante.

Connectez-vous au portail Azure.
Accédez à Applications d’entreprise et sélectionnez Nouvelle application.
Recherchez l’Application ECMA locale, donnez un nom à l’application, puis sélectionnez Créer pour l’ajouter à votre locataire.
Dans le menu, accédez à la page Provisionnement de votre application.
Sélectionnez Prise en main.
Dans la page Provisioning, définissez le mode sur Automatic.

Sous Connectivité locale, sélectionnez Télécharger et installer, puis sélectionnez Accepter les conditions générales et télécharger.

Quittez le portail et ouvrez le programme d’installation de l’agent d’approvisionnement, acceptez les conditions d’utilisation du service, puis sélectionnez Installer.
Attendez l’affichage de Assistant Configuration de l’agent d’approvisionnement Microsoft Entra, puis sélectionnez Suivant.
À l’étape Sélectionner une extension, sélectionnez Provisionnement d’application local, puis Suivant.
L’agent de provisionnement utilisera le navigateur web du système d’exploitation pour afficher une fenêtre contextuelle qui vous permettra de vous authentifier dans Microsoft Entra et éventuellement aussi auprès du fournisseur d’identité de votre organisation. Si vous utilisez Internet Explorer comme navigateur sur Windows Server, vous devrez peut-être ajouter les sites web Microsoft à la liste des sites approuvés de votre navigateur pour permettre à JavaScript de s’exécuter correctement.
Communiquez les informations d’identification relatives à un administrateur Microsoft Entra lorsque vous êtes invité à donner votre autorisation. L’utilisateur doit avoir au moins le rôle Administrateur d’identité hybride.
Sélectionnez Confirmer pour confirmer le paramètre. Une fois l’installation réussie, vous pouvez sélectionner Quitter, puis fermer le programme d’installation du Package de l’agent de provisionnement.

Configurer l’application ECMA locale

Dans e portail, dans la section Connectivité locale, sélectionnez l’agent que vous venez de déployer, puis Attribuer les agents.
Gardez cette fenêtre de navigateur ouverte, car vous effectuez l’étape suivante de la configuration à l’aide de l’assistant Configuration.

Configurer le certificat de l’hôte de connecteur ECMA Microsoft Entra

Sur la machine Windows Server où l’agent de provisionnement est installé, cliquez avec le bouton droit sur Assistant Configuration de Microsoft ECMA2Host dans le menu Démarrer, puis exécutez-le en tant qu’administrateur. L’exécution en tant qu’administrateur Windows est obligatoire pour que l’Assistant puisse créer les journaux d’événements Windows nécessaires.
Une fois la configuration de l’hôte du connecteur ECMA démarrée, si c’est la première fois que vous exécutez l’assistant, il vous demande de créer un certificat. Laissez le port par défaut 8585 et sélectionnez Générer un certificat pour générer un certificat. Le certificat généré automatiquement est auto-signé dans le cadre de la racine de confiance. Le réseau SAN correspond au nom d’hôte.
Sélectionnez Enregistrer.

Remarque

Si vous avez choisi de générer un nouveau certificat, notez la date d’expiration du certificat pour ne pas oublier de revenir dans l’Assistant Configuration afin de regénérer le certificat avant son expiration.

Configurer un connecteur LDAP générique

Selon les options que vous sélectionnez, certains écrans de l’Assistant peuvent ne pas être disponibles et les informations peuvent être légèrement différentes. Pour les besoins de cet exemple de configuration, le provisionnement des utilisateurs avec la classe d’objets User est montré pour AD LDS et avec la classe d’objets inetOrgPerson pour OpenLDAP. Utilisez les informations ci-dessous pour vous guider dans votre configuration.

Générez un jeton secret qui sera utilisé pour l’authentification de Microsoft Entra ID auprès du connecteur. Le jeton doit contenir au minimum 12 caractères et être unique pour chaque application. Si vous n’avez pas encore de générateur de secrets, vous pouvez utiliser une commande PowerShell comme la suivante pour générer un exemple de chaîne aléatoire.
```
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
```
Si vous ne l’avez pas déjà fait, lancez l’assistant Configuration de Microsoft ECMA2Host à partir du menu Démarrer.
Sélectionnez Nouveau connecteur.

Dans la page Properties, renseignez les zones avec les valeurs spécifiées dans le tableau qui suit l’image, puis sélectionnez Next.

Propriété	Valeur
Nom	Nom que vous avez choisi pour le connecteur, qui doit être unique sur tous les connecteurs de votre environnement. Par exemple, `LDAP`.
Minuteur de synchronisation automatique (minutes)	120
Jeton secret	Entrez votre jeton secret ici. Elle doit comporter 12 caractères au minimum.
Extension DLL	Pour le connecteur LDAP générique, sélectionnez Microsoft.IAM.Connector.GenericLdap.dll.

Dans la page Connectivité, vous configurez la façon dont l’hôte du connecteur ECMA communiquera avec le serveur d’annuaire et vous définissez plusieurs options de configuration. Renseignez les zones avec les valeurs spécifiées dans le tableau qui suit l’image, puis sélectionnez Next. Lorsque vous sélectionnez Suivant, le connecteur interroge le serveur d’annuaire pour connaître sa configuration.

Propriété	Description
Hôte	Nom d’hôte où se trouve le serveur LDAP. Cet exemple utilise `APP3` comme nom d’hôte.
Port	Numéro du port TCP. Si le serveur d’annuaire est configuré pour LDAP sur SSL, utilisez le port 636. Pour `Start TLS`, ou si vous utilisez la sécurité au niveau du réseau, utilisez le port 389.
Connection Timeout	180
Liaison	Cette propriété spécifie de quelle façon le connecteur s’authentifiera auprès du serveur d’annuaire. Avec le paramètre `Basic`, ou avec le paramètre `SSL` ou `TLS` et aucun certificat client configuré, le connecteur envoie une liaison LDAP simple pour s’authentifier avec un nom unique et un mot de passe. Avec le paramètre `SSL` ou `TLS` et un certificat client spécifié, le connecteur envoie une liaison `EXTERNAL` SASL LDAP pour s’authentifier avec un certificat client.
User Name	Comment le connecteur ECMA s’authentifiera auprès du serveur d’annuaire. Dans cet exemple, l’exemple de nom d’utilisateur est `CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab` pour AD LDS et `cn=admin,dc=contoso,dc=lab` pour OpenLDAP.
Mot de passe	Mot de passe de l’utilisateur pour lequel le connecteur ECMA s’authentifiera auprès du serveur d’annuaire.
Realm/Domaine	Ce paramètre est obligatoire uniquement si vous avez sélectionné `Kerberos` comme option de liaison, pour fournir les informations Realm/Domaine de l’utilisateur.
Certificat	Les paramètres de cette section sont utilisés seulement si vous avez sélectionné `SSL` ou `TLS` comme option de liaison.
Alias d'attribut	La zone de texte Alias d’attribut est utilisée pour les attributs définis dans le schéma avec la syntaxe RFC4522. Ces attributs ne peuvent pas être détectés durant la détection du schéma, et le connecteur a besoin d’aide pour les identifier. Par exemple, si le serveur d’annuaire ne publie pas `userCertificate;binary` et que vous souhaitez configurer cet attribut, la chaîne suivante doit être entrée dans la zone des alias d’attribut pour identifier correctement l’attribut userCertificate en tant qu’attribut binaire : `userCertificate;binary`. Si vous n’avez pas besoin d’attributs spéciaux qui ne sont pas dans le schéma, vous pouvez laisser ce champ vide.
Inclure les attributs opérationnels	Cochez la case `Include operational attributes in schema` pour inclure également les attributs créés par le serveur d’annuaire. Elle inclut des attributs, notamment la date à laquelle l’objet a été créé et l’heure de la dernière mise à jour.
Inclure les attributs extensibles	Cochez la case `Include extensible attributes in schema` si des objets extensibles (RFC4512/4.3) sont utilisés dans le serveur d’annuaire. L’activation de cette option permet l’utilisation de chaque attribut sur tous les objets. Cette option peut rendre le schéma très volumineux. Alors, à moins que l’annuaire connecté n’utilise cette fonction, il est conseillé de garder cette option désactivée.
Autoriser la sélection manuelle d’ancre	Laissez la case non activée.

Remarque

Si vous rencontrez un problème en essayant de vous connecter et que vous ne parvenez pas à accéder à la page Global, vérifiez que le compte de service dans AD LDS ou l’autre serveur d’annuaire est activé.

Dans la page Global, vous définissez le nom unique du journal des modifications différentielles, au besoin, et d’autres fonctionnalités LDAP. La page est prérenseignée avec les informations fournies par le serveur LDAP. Vérifiez les valeurs affichées, puis sélectionnez Suivant.

Propriété	Description
Mécanismes SASL pris en charge	La section supérieure montre les informations fournies par le serveur lui-même, notamment la liste des mécanismes SASL.
Détails sur les certificats de serveur	Si `SSL` ou `TLS` a été spécifié, l’Assistant affiche le certificat retourné par le serveur d’annuaire. Vérifiez que l’émetteur, l’objet et l’empreinte sont destinés au serveur d’annuaire approprié.
Fonctionnalités obligatoires trouvées	Le connecteur vérifie également que les contrôles obligatoires sont présents dans la DSE racine. Si tel n’est pas le cas, un avertissement s’affiche. Certains répertoires LDAP ne répertorient pas toutes les fonctionnalités de la DSE racine. Il est possible que le connecteur fonctionne sans problème, même si un avertissement s’affiche.
Contrôles pris en charge	Les cases à cocher des commandes prises en charge contrôlent le comportement de certaines opérations
Importation d’écart	Le DN du journal des modifications est le contexte de nommage utilisé par le journal des modifications différentielles, par exemple, cn=changelog. Vous devez spécifier cette valeur pour pouvoir effectuer une importation différentielle.
Attribut de mot de passe	Si le serveur d’annuaire prend en charge un attribut de mot de passe ou un hachage de mot de passe différent, vous pouvez spécifier la destination pour les changements de mots de passe.
Noms de partition	Dans la liste des partitions supplémentaires, il est possible d’ajouter des espaces de noms supplémentaires qui ne sont pas automatiquement détectés. Cela peut être utile, par exemple, si plusieurs serveurs forment un cluster logique et doivent être importés simultanément. Active Directory peut compter plusieurs domaines partageant le même schéma dans une forêt. On peut simuler cette situation en saisissant les espaces de noms supplémentaires dans cette zone. Chaque espace de noms peut effectuer une importation à partir de différents serveurs et être configuré dans la page Configurer des partitions et des hiérarchies.

Dans la page Partitions , conservez la valeur par défaut, puis sélectionnez Suivant.

Dans la page Profils d’exécution, vérifiez que la case à cocher Exporter et la case à cocher Importation complète sont toutes deux cochées. Sélectionnez ensuite Suivant.

Propriété	Description
Exporter	Profil d’exécution qui exportera les données vers le serveur d’annuaire LDAP. Ce profil d’exécution est obligatoire.
Importation intégrale	Profil d’exécution qui va importer toutes les données depuis les sources LDAP spécifiées précédemment. Ce profil d’exécution est obligatoire.
Importation différentielle	Profil d’exécution qui va importer seulement les modifications de LDAP depuis la dernière importation complète ou différentielle. Activez ce profil d’exécution uniquement si vous avez vérifié que le serveur d’annuaire remplit bien les exigences appropriées. Pour plus d’informations, consultez la référence du connecteur LDAP générique.

Dans la page Exporter, conservez les mêmes valeurs par défaut et cliquez sur Suivant.
Dans la page Importation complète, conservez les mêmes valeurs par défaut et cliquez sur Suivant.
Dans la page Importation différentielle, le cas échéant, conservez les mêmes valeurs par défaut et cliquez sur Suivant.

Dans la page Object Types, renseignez les zones et sélectionnez Next.

Propriété	Description
Objet cible	Cette valeur correspond à la classe d’objets structurelle d’un utilisateur sur le serveur d’annuaire LDAP. Par exemple, `inetOrgPerson` pour OpenLDAP ou `User` pour AD LDS. Ne spécifiez pas de classe d’objets auxiliaire dans ce champ. Si le serveur d’annuaire nécessite des classes d’objets auxiliaires, celles-ci sont configurées avec les mappages d’attributs dans le portail Azure.
Ancre	Les valeurs de cet attribut doivent être uniques pour chaque objet dans l’annuaire cible. Le service d’approvisionnement Microsoft Entra va interroger l’hôte du connecteur ECMA à l’aide de cet attribut après le cycle initial. Pour AD LDS, utilisez `ObjectGUID`. Pour les autres serveurs d’annuaire, consultez le tableau suivant. Notez que le nom unique peut être sélectionné comme `-dn-`. Les attributs à valeurs multiples, tels que l’attribut `uid` dans le schéma OpenLDAP, ne peuvent pas être utilisés comme ancres.
Query Attribute	Cet attribut doit être identique à l’ancre : par exemple `objectGUID` si AD LDS est le serveur d’annuaire, ou `_distinguishedName` s’il s’agit d’OpenLDAP.
DN	Nom unique (distinguishedName) de l’objet cible. Conservez `-dn-`.
Généré automatiquement	désactivé

Le tableau ci-dessous liste les serveurs LDAP et l’ancre utilisée :

Répertoire	Ancre
Microsoft AD LDS et AD GC	GUID de l’objet (objectGUID). Vous devez avoir installé l’agent version 1.1.846.0 ou ultérieure pour utiliser `ObjectGUID` comme ancre.
Serveur d’annuaire 389	dn
Apache Directory	dn
IBM Tivoli DS	dn
Isode Directory	dn
Novell/NetIQ eDirectory	GUID
DJ/DS Open	dn
LDAP Open	dn
Oracle ODSEE	dn
RadiantOne VDS	dn
Sun One Directory Server	dn

L’hôte ECMA découvre les attributs pris en charge par l’annuaire cible. Parmi eux, vous pouvez choisir ceux que vous souhaitez exposer à Microsoft Entra ID. Ces attributs peuvent ensuite être configurés dans le portail Azure pour l’approvisionnement. Dans la page Sélectionner des attributs, ajoutez un par un tous les attributs de la liste déroulante qui sont des attributs obligatoires ou que vous souhaitez attribuer à partir de Microsoft Entra ID.
La liste déroulante Attribut montre tous les attributs qui ont été découverts dans l’annuaire cible et qui n’ont pas été sélectionnés précédemment dans la page Sélectionner des attributs de l’Assistant Configuration.

Assurez-vous que la case Treat as single value est décochée pour l’attribut objectClass, ainsi que pour l’attribut userPassword si userPassword est défini.

Si vous utilisez OpenLDAP avec le schéma inetOrgPerson, configurez la visibilité pour les attributs suivants.

Attribut	Traiter comme une valeur unique
cn	O
mail	O
objectClass
sn	O
userPassword	O

Si vous utilisez OpenLDAP avec le schéma POSIX, configurez la visibilité pour les attributs suivants.

Attribut	Traiter comme une valeur unique
_distinguishedName
-dn-
export_password
cn	O
gidNumber
homeDirectory
mail	O
objectClass
sn	O
uid	O
uidNumber
userPassword	O

Une fois tous les attributs pertinents ajoutés, sélectionnez Suivant.

Dans la page Déprovisionner, vous pouvez spécifier si vous souhaitez que Microsoft Entra ID supprime les utilisateurs de l’annuaire quand ils sortent de l’étendue de l’application. Si c’est le cas, sous Désactiver le flux, sélectionnez Supprimer, puis sous Supprimer le flux, sélectionnez Supprimer. Si Set attribute value est choisi, les attributs sélectionnés dans la page précédente ne pourront pas être sélectionnés dans la page Déprovisionner.

Remarque

Si vous utilisez Définir la valeur de l’attribut, sachez que seules les valeurs booléennes sont autorisées.

Sélectionnez Terminer.

Vérifiez que le service ECMA2Host est en cours d’exécution et qu’il peut lire à partir du serveur d’annuaire.

Suivez ces étapes pour vérifier que l’hôte du connecteur a démarré et a identifié tous les utilisateurs existants du serveur d’annuaire dans l’hôte du connecteur.

Sur le serveur sur lequel s’exécute l’hôte du connecteur ECMA Microsoft Entra, sélectionnez Démarrer.
Sélectionnez run si nécessaire, puis entrez services.msc dans la zone.
Dans la liste Services, vérifiez que Microsoft ECMA2Host est présent et en cours d’exécution. S’il n’est pas en cours d’exécution, sélectionnez Démarrer.
Si vous avez démarré le service récemment et que vous avez de nombreux objets utilisateur dans le serveur d’annuaire, patientez quelques minutes le temps que le connecteur établisse une connexion au serveur d’annuaire.
Sur le serveur sur lequel s’exécute l’hôte du connecteur ECMA Microsoft Entra, lancez PowerShell.
Accédez au dossier dans lequel l’hôte ECMA a été installé, par exemple C:\Program Files\Microsoft ECMA2Host.
Accédez au sous-répertoire Troubleshooting.
Exécutez le script TestECMA2HostConnection.ps1 dans cet annuaire comme indiqué dans l’exemple suivant, et fournissez comme arguments le nom du connecteur et la ObjectTypePath valeur cache. Si votre hôte de connecteur n’écoute pas sur le port TCP 8585, vous devrez peut-être également fournir l’argument -Port. Lorsque vous y êtes invité, tapez le jeton secret configuré pour ce connecteur.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
```
Si le script affiche un message d’erreur ou d’avertissement, vérifiez que le service est en cours d’exécution, et que le nom du connecteur et le jeton secret correspondent aux valeurs que vous avez configurées dans l’Assistant Configuration.
Si le script affiche la sortie False, cela indique que le connecteur n’a trouvé aucune entrée dans le serveur d’annuaire source pour les utilisateurs existants. S’il s’agit de l’installation d’un nouveau serveur d’annuaire, ce comportement est normal et vous pouvez continuer à la section suivante.
Toutefois, si le serveur d’annuaire contient déjà un ou plusieurs utilisateurs mais que le script a affiché False, cet état indique que le connecteur n’a pas pu lire à partir du serveur d’annuaire. Si vous tentez l’approvisionnement, Microsoft Entra ID risque de ne pas faire correspondre correctement les utilisateurs de cet annuaire source avec les utilisateurs de Microsoft Entra ID. Patientez quelques minutes le temps que l’hôte de connecteur termine la lecture des objets à partir du serveur d’annuaire existant, puis réexécutez le script. Si la sortie obtenue est toujours False, vérifiez la configuration du connecteur et assurez-vous que le connecteur a les autorisations appropriées pour lire les utilisateurs existants sur le serveur d’annuaire.

Tester la connexion entre Microsoft Entra ID et l’hôte du connecteur

Revenez à la fenêtre du navigateur web où vous configuriez le provisionnement d’applications dans le portail.

Remarque

Si la fenêtre a expiré, vous devrez sélectionner l’agent à nouveau.
1. Connectez-vous au portail Azure.
2. Accédez à Applications d’entreprise, puis à l’application On-premises ECMA app.
3. Cliquez sur Approvisionnement.
4. Si Prise en main s’affiche, remplacez le mode par Automatique, dans la section Connectivité locale, sélectionnez l’agent que vous venez de déployer, puis Affecter des agents, et patientez 10 minutes. Sinon, accédez à Modifier l’approvisionnement.
Dans la section Informations d’identification de l’administrateur, entrez l’URL suivante. Remplacez la partie connectorName par le nom du connecteur sur l’hôte ECMA, par exemple LDAP. Si vous avez fourni un certificat de votre autorité de certification pour l’hôte ECMA, remplacez localhost par le nom d’hôte du serveur où l’hôte ECMA est installé.

Propriété Valeur

URL de locataire https://localhost:8585/ecma2host_connectorName/scim
Entrez la valeur Secret Token que vous avez définie lors de la création du connecteur.

Remarque

Si vous venez d’attribuer l’agent à l’application, patientez 10 minutes pour que l’inscription se termine. Le test de connectivité ne fonctionne pas tant que l’inscription n’est pas terminée. Pour accélérer le processus d’inscription, vous pouvez forcer l’inscription de l’agent en redémarrant l’agent d’approvisionnement sur votre serveur. Accédez à votre serveur, recherchez services dans la barre de recherche Windows, identifiez le service Agent d’approvisionnement Microsoft Entra Connect, cliquez avec le bouton droit sur le service, puis redémarrez.
Sélectionnez Test Connection et patientez une minute.
Une fois que le test de connexion est réussi et qu'il indique que les informations d'identification fournies sont autorisées à activer le provisionnement, sélectionnez Enregistrer.

Propriété	Valeur
URL de locataire	https://localhost:8585/ecma2host_connectorName/scim

Étendre le schéma Microsoft Entra (optionnel)

Il est possible que votre serveur d’annuaire nécessite des attributs supplémentaires non compris dans le schéma Microsoft Entra par défaut pour les utilisateurs. Dans ce cas, vous pouvez établir la configuration de manière à fournir les valeurs de ces attributs à partir d’une constante ou d’une expression transformée à partir d’autres attributs Microsoft Entra, ou en étendant le schéma Microsoft Entra.

Le serveur d’annuaire peut également demander aux utilisateurs de disposer d’un attribut, tel que uidNumber pour le schéma POSIX OpenLDAP. Il est possible que cet attribut ne soit pas encore inclus dans votre schéma Microsoft Entra pour l’utilisateur et qu’il doive être unique pour chaque utilisateur. Dans ce cas, vous devez soit générer cet attribut à partir d’attributs de l’utilisateur à l’aide d’une expression, soit utiliser la fonctionnalité d’extension d’annuaire pour ajouter cet attribut en tant qu’extension.

Si vos utilisateurs proviennent d’Active Directory Domain Services et que leur attribut se trouve dans ce répertoire, vous pouvez utiliser Microsoft Entra Connect ou la synchronisation cloud Microsoft Entra Connect pour configurer la synchronisation de l’attribut entre Active Directory Domain Services et Microsoft Entra. Ainsi, l’attribut peut être approvisionné sur d’autres systèmes.

Si vos utilisateurs proviennent de Microsoft Entra, pour chaque nouvel attribut que vous devez stocker sur un utilisateur, vous devez définir une extension d’annuaire. Ensuite, mettez à jour les utilisateurs Microsoft Entra dont l’attribution est prévue pour donner à chaque utilisateur une valeur de ces attributs.

Configurer le mappage d’attributs

Dans cette section, vous allez configurer le mappage entre les attributs des utilisateurs Microsoft Entra et les attributs que vous avez sélectionnés précédemment dans l’Assistant Configuration de l’hôte ECMA. Plus tard, lorsque le connecteur créera un objet dans un serveur d’annuaire, les attributs d’un utilisateur Microsoft Entra seront ensuite envoyés via le connecteur au serveur d’annuaire pour faire partie de ce nouvel objet.

Dans le Centre d’administration Microsoft Entra, sous Applications d’entreprise, sélectionnezApplication ECMA locale, puis la page Approvisionnement.
Sélectionnez Modifier le provisionnement.
Développez Mappages et sélectionnez Configurer les utilisateurs Microsoft Entra. Si c’est la première fois que vous configurez les mappages d’attributs pour cette application, il n’y a qu’un seul mappage présent pour un espace réservé.
Pour vérifier que le schéma du serveur d’annuaire est disponible dans Microsoft Entra ID, cochez la case Afficher les options avancées, puis sélectionnez Modifier la liste d’attributs pour ScimOnPremises. Vérifiez que tous les attributs sélectionnés dans l’Assistant Configuration sont listés. Si ce n’est pas le cas, attendez plusieurs minutes que le schéma s’actualise, sélectionnez Mappage d’attributs dans la ligne de navigation, puis resélectionnez Modifier la liste d’attributs pour ScimOnPremises pour recharger la page. Quand vous voyez les attributs listés, quittez cette page pour revenir à la liste des mappages.
Chaque utilisateur dans un annuaire doit avoir un nom unique (DN). Vous pouvez spécifier la façon dont le connecteur doit former un nom unique à l’aide d’un mappage d’attributs. Sélectionnez Ajouter un mappage. Utilisez les valeurs de l’exemple suivant pour créer le mappage, en remplaçant les noms uniques dans l’expression pour qu’ils correspondent à ceux de l’unité d’organisation ou d’un autre conteneur dans votre annuaire cible.
- Type de mappage : expression
- Expression, si le provisionnement est dans AD LDS : Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
- Expression, si le provisionnement est dans OpenLDAP : Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- Attribut cible : urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- Appliquer ce mappage : uniquement durant la création d’objet
Si le serveur d’annuaire impose de fournir plusieurs valeurs de classe d’objet structurelle, ou valeurs de classe d’objet auxiliaire, dans l’attribut objectClass, ajoutez un mappage à cet attribut. Pour cet exemple d’approvisionnement dans AD LDS, le mappage de objectClass n’est pas demandé, mais il peut être requis pour d’autres serveurs d’annuaire ou d’autres schémas. Pour ajouter un mappage de objectClass, sélectionnez Ajouter un nouveau mappage. Utilisez les valeurs de l’exemple suivant pour créer le mappage, en remplaçant les noms de classes d’objets dans l’expression pour qu’ils correspondent à ceux du schéma de l’annuaire cible.
- Type de mappage : expression
- Expression, s’il s’agit du provisionnement du schéma inetOrgPerson : Split("inetOrgPerson",",")
- Expression, s’il s’agit du provisionnement du schéma POSIX : Split("inetOrgPerson,posixAccount,shadowAccount",",")
- Attribut cible : urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- Appliquer ce mappage : uniquement durant la création d’objet
Si vous effectuez un approvisionnement dans AD LDS et qu’un mappage est présent entre userPrincipalName et PLACEHOLDER, cliquez sur ce mappage et modifiez-le. Mettez à jour le mappage avec les valeurs suivantes.
- Type de mappage : direct
- Attribut source : userPrincipalName
- Attribut cible : urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
- Priorité de correspondance : 1
- Appliquer ce mappage : uniquement durant la création d’objet
Si vous effectuez un approvisionnement dans AD LDS, ajoutez un mappage pour isSoftDeleted. Sélectionnez Ajouter un mappage. Créez le mappage avec les valeurs suivantes.
- Type de mappage : direct
- Attribut source : isSoftDeleted
- Attribut cible : urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

Pour chacun des mappages listés dans le tableau suivant pour votre serveur d’annuaire, sélectionnez Ajouter un nouveau mappage et spécifiez les attributs source et cible. Si vous approvisionnez dans un annuaire existant avec des utilisateurs existants, vous devez modifier le mappage de l’attribut en commun pour définir Trouver les objets utilisant cet attribut pour cet attribut. Découvrez plus d’informations sur le mappage des attributs ici.

Pour AD LDS :

Type de mappage	Attribut source	Attribut cible
Direct	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName`

Pour OpenLDAP :

Type de mappage	Attribut source	Attribut cible
Direct	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
Direct	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
Direct	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`

Pour OpenLDAP avec le schéma POSIX, vous devez également fournir les attributs gidNumber, homeDirectory, uid et uidNumber. Chaque utilisateur nécessite un uid unique et un uidNumber unique. En règle générale, le homeDirectory est défini par une expression dérivée de l’userID de l’utilisateur. Par exemple, si le uid d’un utilisateur est généré par une expression dérivée de son nom d’utilisateur principal, la valeur du répertoire de base de cet utilisateur peut être générée par une expression similaire, également dérivée de son nom d’utilisateur principal. En outre, selon votre cas d’usage, vous souhaiterez peut-être que tous les utilisateurs se trouvent dans le même groupe. Vous devrez alors assigner le gidNumber à partir d’une constante.

Type de mappage	Attribut source	Attribut cible
Expression	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
Direct	(attribut spécifique à votre répertoire)	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber`
Expression	`Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory`
Constant	`10000`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber`

Si vous effectuez l’approvisionnement dans un répertoire autre qu’AD LDS, ajoutez un mappage à urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword afin de définir un mot de passe aléatoire initial pour l’utilisateur. Pour AD LDS, il n’existe aucun mappage de userPassword.
Sélectionnez Enregistrer.

Vérifier que les utilisateurs à approvisionner dans l’application possèdent les attributs requis dans Microsoft Entra ID

Si certains utilisateurs disposent de comptes existants dans l’annuaire LDAP, vous devez vous assurer que la représentation des utilisateurs Microsoft Entra est associée aux attributs nécessaires pour effectuer la correspondance.

Si vous envisagez de créer de nouveaux utilisateurs dans l’annuaire LDAP, vous devez vous assurer que leurs représentations Microsoft Entra sont associées aux attributs source requis par le schéma utilisateur du répertoire cible.

Vous pouvez utiliser les cmdlets de commande PowerShell Microsoft Graph afin d’automatiser la vérification des attributs requis pour les utilisateurs.

Par exemple, supposons que votre approvisionnement exige que les utilisateurs soient associés à trois attributs DisplayName,surname et extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Vous pouvez utiliser le cmdlet Get-MgUser pour récupérer chaque utilisateur et vérifier si les attributs requis sont présents. Notez que le cmdlet Get-MgUser de Graph v1.0 ne renvoie par défaut aucun des attributs d'extension de répertoire d'un utilisateur, à moins que les attributs ne soient spécifiés dans la requête comme l'une des propriétés à renvoyer.

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

Collectez les utilisateurs existants à partir de l’annuaire LDAP

La plupart des annuaires LDAP, comme Active Directory, comprennent une commande qui génère une liste d’utilisateurs.

Identifiez les utilisateurs de l’annuaire qui se trouvent dans l’étendue des utilisateurs de l’application. Ce choix dépend de la configuration de votre application. Pour certaines applications, tout utilisateur qui existe dans un annuaire LDAP est un utilisateur valide. D’autres applications peuvent exiger de l’utilisateur qu’il possède un attribut particulier ou qu’il soit membre d’un groupe de cet annuaire.
Exécutez la commande qui récupère ce sous-ensemble d’utilisateurs à partir de votre annuaire LDAPS. Vérifiez que la sortie comprend les attributs d’utilisateurs qui seront utilisés pour la mise en correspondance avec Microsoft Entra ID. par exemple, l’ID d’employé, le nom du compte et l’adresse e-mail.

Par exemple, cette commande sous Windows par l’intermédiaire du programme AD LDS csvde produit un fichier CSV dans l’annuaire actif avec l’attribut userPrincipalName de chaque personne de l’annuaire :
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
Si nécessaire, transférez le fichier CSV contenant la liste des utilisateurs vers un système avec les cmdlets Microsoft Graph PowerShell installées.
Maintenant que vous avez obtenu la liste de tous les utilisateurs de l’application, vous devez mettre en correspondance ces utilisateurs du magasin de données de l’application avec les utilisateurs de Microsoft Entra ID. Avant de continuer, consultez les informations sur la correspondance des utilisateurs dans les systèmes source et cible.

Récupérer les ID des utilisateurs dans Microsoft Entra ID

Cette section montre comment interagir avec Microsoft Entra ID à l’aide de cmdlets Microsoft Graph PowerShell.

La première fois que votre organisation utilise ces cmdlets pour ce scénario, vous devez avoir un rôle d’administrateur général pour autoriser l’utilisation de Microsoft Graph PowerShell dans votre locataire. Les interactions suivantes peuvent utiliser un rôle avec des privilèges inférieurs, par exemple :

Administrateur d’utilisateurs si vous prévoyez de créer des utilisateurs
Administrateur d’application ou Administrateur de gouvernance des identités si vous gérez simplement des attributions de rôles d’application

Ouvrez PowerShell.
Si les modules Microsoft Graph PowerShell ne sont pas déjà installés, installez le module Microsoft.Graph.Users et les autres à l’aide de cette commande :
```
Install-Module Microsoft.Graph
```
Si les modules sont déjà installés, vérifiez que vous utilisez une version récente :
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Connectez-vous à Microsoft Entra ID :

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

Si c’est la première fois que vous utilisez cette commande, vous devrez peut-être consentir à ce que les outils en ligne de commande Microsoft Graph disposent de ces autorisations.
Lisez la liste des utilisateurs obtenue à partir du magasin de données de l’application dans la session PowerShell. Si la liste des utilisateurs était stockée dans un fichier CSV, vous pouvez utiliser la cmdlet PowerShell Import-Csv et fournir le nom du fichier de la section précédente comme argument.

Par exemple, si le fichier obtenu depuis SAP Cloud Identity Services se nomme Users-exported-from-sap.csv et se trouve dans le répertoire actif, entrez cette commande.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Dans le cas où vous utilisez une base de données ou un répertoire, si le fichier est nommé users.csv et se trouve dans le répertoire actif, entrez cette commande :
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Choisissez la colonne du fichier users.csv qui correspond à un attribut d’un utilisateur dans Microsoft Entra ID.

Si vous utilisez SAP Cloud Identity Services, l’attribut SAP SCIM userName et l’attribut Microsoft Entra ID userPrincipalName sont mappés par défaut :
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Dans le cas où vous utilisez une base de données ou un répertoire, vous pouvez avoir dans la base de données des utilisateurs dont la valeur dans la colonne nommée EMail est identique à celle contenue dans l’attribut Microsoft Entra userPrincipalName :
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Récupérez les ID de ces utilisateurs dans Microsoft Entra ID.

Le script PowerShell suivant utilise les valeurs $dbusers, $db_match_column_nameet $azuread_match_attr_name spécifiées précédemment. Le système interroge Microsoft Entra ID pour localiser un utilisateur ayant un attribut avec une valeur correspondante pour chaque enregistrement du fichier source. Si de nombreux utilisateurs existent dans le fichier obtenu depuis la source SAP Cloud Identity Services, la base de données ou le répertoire, ce script peut prendre plusieurs minutes. Si aucun attribut dans Microsoft Entra ID n’a cette valeur et que vous devez utiliser une expression contains ou une autre expression de filtre, vous devez personnaliser ce script et celui de l’étape 11 plus bas.

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

Examinez les résultats des requêtes précédentes. Vérifiez si l’un des utilisateurs de SAP Cloud Identity Services, de la base de données ou du répertoire n’a pas pu être localisé dans Microsoft Entra ID en raison d’erreurs ou de correspondances manquantes.

Le script PowerShell suivant affiche le nombre d’enregistrements qui n’ont pas été localisés :

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

Quand le script est terminé, il indique une erreur si des enregistrements de la source de données n’ont pas été localisés dans Microsoft Entra ID. Si certains enregistrements d’utilisateurs du magasin de données de l’application n’ont pas pu être localisés comme utilisateurs dans Microsoft Entra ID, vous devez investiguer les enregistrements qui n’ont pas eu de correspondance et pourquoi.

Par exemple, l’adresse e-mail et le userPrincipalName d’une personne ont sans doute été modifiés dans Microsoft Entra ID sans que sa propriété mail correspondante ait été mise à jour dans la source de données de l’application. Ou encore, l’utilisateur peut avoir déjà quitté l’organisation et figurer encore dans la source de données de l’application. Autre possibilité : la source de données de l’application contient un compte fournisseur ou de super administrateur qui ne correspond à aucune personne précise dans Microsoft Entra ID.
Si certains utilisateurs n’ont pas pu être localisés dans Microsoft Entra ID ou n’étaient pas actifs et en mesure de se connecter, mais que vous souhaitez que leur accès soit révisé ou que leurs attributs soient mis à jour dans SAP Cloud Identity Services, la base de données ou le répertoire, vous devez mettre à jour l’application, la règle de correspondance, ou mettre à jour ou créer des utilisateurs Microsoft Entra pour eux. Pour plus d’informations sur les modifications à apporter, consultez Gérer les mappages et les comptes d’utilisateur dans les applications qui ne correspondent pas à des utilisateurs dans Microsoft Entra ID.

Si vous choisissez de créer des utilisateurs dans Microsoft Entra ID, vous pouvez le faire en bloc en utilisant l’une des options suivantes :
- Fichier CSV comme décrit dans Créer des utilisateurs en bloc dans le centre d’administration Microsoft Entra
- Avec la cmdlet New-MgUser
Veillez à ce que ces nouveaux utilisateurs soient renseignés avec les attributs nécessaires à Microsoft Entra ID pour les mettre en correspondance par la suite avec les utilisateurs existants de l’application et avec les attributs nécessaires à Microsoft Entra ID, y compris userPrincipalName, mailNickname et displayName. Le userPrincipalName doit être unique parmi tous les utilisateurs de l’annuaire.

Par exemple, vous pouvez avoir des utilisateurs dans la base de données où la valeur dans la colonne nommée EMail est celle que vous voulez utiliser comme nom d’utilisateur principal Microsoft Entra, où la valeur dans la colonne Alias contient le pseudonyme de messagerie Microsoft Entra ID et où la valeur dans la colonne Full name contient le nom complet de l’utilisateur :
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
Vous pouvez ensuite utiliser ce script pour créer des utilisateurs Microsoft Entra pour ceux présents dans SAP Cloud Identity Services, la base de données ou le répertoire et qui ne correspondaient pas à des utilisateurs dans Microsoft Entra ID. Notez qu’il peut être nécessaire de modifier ce script pour ajouter des attributs Microsoft Entra supplémentaires nécessaires dans votre organisation, ou si le $azuread_match_attr_name n’est ni mailNickname ni userPrincipalName, pour fournir cet attribut Microsoft Entra.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

Après avoir ajouté les éventuels utilisateurs manquants à Microsoft Entra ID, réexécutez le script de l’étape 7. Exécutez ensuite le script de l’étape 8. Vérifiez qu’aucune erreur n’est signalée.

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

Affecter des utilisateurs à une application

Maintenant que l’hôte du connecteur ECMA Microsoft Entra est capable de communiquer avec Microsoft Entra ID, et que le mappage des attributs est configuré, vous pouvez passer à la configuration de l’étendue de l’approvisionnement.

Important

Si vous étiez connecté avec un rôle Administrateur d’identité hybride, vous devez vous déconnecter et vous connecter avec un compte disposant au moins du rôle Administrateur d’application pour cette section. Le rôle Administrateur d’identité hybride ne dispose pas des autorisations nécessaires pour affecter des utilisateurs à des applications.

S’il existe des utilisateurs dans l’annuaire LDAP, vous devez leur créer des attributions de rôles d’application dans Microsoft Entra ID. Pour en savoir plus sur la création en bloc d’attributions de rôles d’application à l’aide de New-MgServicePrincipalAppRoleAssignedTo, consultez l’article Gouvernance des utilisateurs existants d’une application dans Microsoft Entra ID.

En revanche, si l’annuaire LDAP est vide, sélectionnez un utilisateur test dans Microsoft Entra ID avec les attributs requis afin qu’il soit attribué au serveur d’annuaire de l’application.

Assurez-vous que l’utilisateur qui va être sélectionné a toutes les propriétés qui seront mappées aux attributs requis par le schéma du serveur d’annuaire.
Dans le portail Azure, sélectionnez Applications d’entreprise.
Sélectionnez l’application Application ECMA locale.
À gauche, sous Gérer, sélectionnez Utilisateurs et groupes.
Sélectionner Ajouter un utilisateur/groupe.
Sous Utilisateurs, sélectionnez Aucun sélectionné.
Sélectionnez des utilisateurs à droite, puis cliquez sur le bouton Sélectionner.
Sélectionnez Affecter.

Tester le provisionnement

Maintenant que vos attributs sont mappés et que les utilisateurs sont affectés, vous pouvez tester l’approvisionnement à la demande avec l’un de vos utilisateurs.

Sur le serveur sur lequel s’exécute l’hôte du connecteur ECMA Microsoft Entra, sélectionnez Démarrer.
Entrez run et tapez services.msc dans la zone.
Dans la liste Services, vérifiez que le service Microsoft Entra Connect Provisioning Agent et les services Microsoft ECMA2Host sont en cours d’exécution. Si ce n’est pas le cas, sélectionnez Démarrer.
Dans le portail Azure, sélectionnez Applications d’entreprise.
Sélectionnez l’application Application ECMA locale.
Sur la gauche, sélectionnez Provisionnement.
Sélectionnez Approvisionner à la demande.
Recherchez l’un de vos utilisateurs de test, puis sélectionnez Provisionner.
Après plusieurs secondes, le message Utilisateur créé dans le système cible s’affiche, avec une liste des attributs utilisateur. Si une erreur s’affiche à la place, consultez la résolution des erreurs d’approvisionnement.

Démarrer le provisionnement des utilisateurs

Une fois le test d’approvisionnement à la demande réussi, ajoutez les utilisateurs restants.

Sélectionnez l’application dans le portail Azure.
À gauche, sous Gérer, sélectionnez Utilisateurs et groupes.
Assurez-vous que le rôle d’application est affecté à tous les utilisateurs.
Revenez à la page de configuration de l’approvisionnement.
Vérifiez que l’étendue est définie sur les seuls utilisateurs et groupes attribués, activez le provisionnement, puis sélectionnez Enregistrer.
Attendez que le provisionnement démarre. Cela peut prendre jusqu’à 40 minutes. Une fois la tâche d’approvisionnement effectuée, passez à la section suivante.

Résolution des erreurs de provisionnement

Si une erreur s’affiche, sélectionnez Afficher les journaux de provisionnement. Recherchez dans le journal une ligne dans laquelle l’état est Échec, puis cliquez sur cette ligne.

Si le message d’erreur est Échec de la création de l’utilisateur, vérifiez les attributs affichés par rapport aux exigences du schéma d’annuaire.

Pour plus d’informations, accédez à l’onglet Résolution des problèmes et recommandations.

Si le message d’erreur issu de la résolution des problèmes indique qu’une valeur objectClass est invalid per syntax, vérifiez que le mappage de l’attribut d’approvisionnement à l’attribut objectClass inclut uniquement les noms de classes d’objets reconnues par le serveur d’annuaire.

Pour d’autres erreurs, consultez Résolution des problèmes d’approvisionnement d’applications locales.

Si vous souhaitez interrompre l’approvisionnement de cette application, passez l’état d’approvisionnement à Désactivé dans la page de configuration de l’approvisionnement, puis sélectionnez Enregistrer. Cette action empêche que le service de provisionnement s’exécute à l’avenir.

Vérifier que les utilisateurs ont été correctement provisionnés

Après un temps d’attente, vérifiez dans votre serveur d’annuaire que les utilisateurs ont bien été provisionnés. La requête que vous adressez au serveur d’annuaire dépend des commandes que celui-ci fournit.

Les instructions suivantes montrent comment vérifier AD LDS.

Ouvrez le Gestionnaire de serveur et sélectionnez AD LDS à gauche
Cliquez avec le bouton droit sur votre instance AD LDS et sélectionnez ldp.exe dans la fenêtre contextuelle.
En haut de ldp.exe, sélectionnez Connexion et Se connecter.
Entrez les informations suivantes et cliquez sur OK.
- Serveur : APP3
- Port : 636
- Cochez la case SSL
En haut, sous Connexion, sélectionnez Lier.
Acceptez les valeurs par défaut et cliquez sur OK.
En haut, sélectionnez Affichage et Arborescence
Pour BaseDN, entrez CN=App,DC=contoso,DC=lab puis cliquez sur OK.
Sur la gauche, développez le DN, puis cliquez sur CN=CloudUsers,CN=App,DC=contoso,DC=lab. Vous devez voir vos utilisateurs qui ont été attribués à partir de Microsoft Entra ID.

Les instructions suivantes indiquent comment vérifier OpenLDAP.

Ouvrez une fenêtre de terminal avec un interpréteur de commandes du système avec OpenLDAP.
Saisissez la commande ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson).
Vérifiez que le LDIF résultant inclut les utilisateurs attribués à partir de Microsoft Entra ID.

Partager via

Configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP

Conditions préalables pour l’approvisionnement d’utilisateurs dans un répertoire LDAP

Conditions préalables locales

Serveurs d’annuaire LDAP pris en charge

Conditions préalables requises du cloud

Plus de recommandations et restrictions

Sélection des profils d’exécution

Identification des interactions entre le connecteur LDAP Microsoft Entra ID et le serveur d’annuaire

Préparer l’annuaire LDAP

Installer et configurer l’agent d’attribution Microsoft Entra Connect

Configurer l’application ECMA locale

Configurer le certificat de l’hôte de connecteur ECMA Microsoft Entra

Configurer un connecteur LDAP générique

Vérifiez que le service ECMA2Host est en cours d’exécution et qu’il peut lire à partir du serveur d’annuaire.

Tester la connexion entre Microsoft Entra ID et l’hôte du connecteur

Étendre le schéma Microsoft Entra (optionnel)

Configurer le mappage d’attributs

Vérifier que les utilisateurs à approvisionner dans l’application possèdent les attributs requis dans Microsoft Entra ID

Collectez les utilisateurs existants à partir de l’annuaire LDAP

Récupérer les ID des utilisateurs dans Microsoft Entra ID

Affecter des utilisateurs à une application

Tester le provisionnement

Démarrer le provisionnement des utilisateurs

Résolution des erreurs de provisionnement

Vérifier que les utilisateurs ont été correctement provisionnés

Étapes suivantes

Commentaires

Ressources supplémentaires