Configuration de l’ID Microsoft Entra pour approvisionner des utilisateurs dans un répertoire LDAP pour l’authentification Linux

Article
01/24/2025

La documentation suivante est un tutoriel montrant comment régir l’accès à un système Linux. Microsoft Entra approvisionne les utilisateurs dans un répertoire LDAP local approuvé par ce système Linux. Cela permet aux utilisateurs de se connecter à un système Linux qui s’appuie sur ce répertoire LDAP pour l’authentification utilisateur. Lorsqu’un utilisateur est supprimé de l’ID Microsoft Entra, il ne peut plus se connecter à un système Linux.

Note

Le scénario décrit dans cet article s’applique uniquement aux systèmes Linux existants qui s’appuient déjà sur un module LDAP NSS (Name Services Switch) ou PAM (Branchable Authentication Modules) pour l’identification et l’authentification des utilisateurs. Les machines virtuelles Linux dans Azure ou qui sont compatibles avec Azure Arc doivent être intégrées à l’authentification Microsoft Entra. Vous pouvez désormais utiliser Microsoft Entra ID comme plateforme d’authentification principale et une autorité de certification pour SSH dans une machine virtuelle Linux à l’aide de l’authentification basée sur les certificats Microsoft Entra et OpenSSH, comme décrit dans se connecter à une machine virtuelle Linux dans Azure à l’aide de Microsoft Entra ID et d'OpenSSH.

Pour d’autres scénarios impliquant l’approvisionnement d’utilisateurs dans des répertoires LDAP, autres que pour l’authentification Linux, consultez configuration de l’ID Microsoft Entra pour approvisionner des utilisateurs dans des répertoires LDAP.

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

Cet article suppose que le serveur LDAP est déjà présent dans l’environnement local, utilisé par un ou plusieurs systèmes Linux ou d’autres systèmes POSIX pour l’authentification utilisateur.

Diagramme montrant l’architecture de l’approvisionnement local de Microsoft Entra ID vers un serveur d’annuaire LDAP.

Conditions préalables locales

Un serveur Linux ou un autre serveur POSIX qui répond sur un serveur d’annuaire à l’aide d’un module PAM ou NSS.
Un serveur d’annuaire LDAP qui prend en charge le schéma POSIX, tel qu’OpenLDAP, dans lequel les utilisateurs peuvent être créés, mis à jour et supprimés. Pour plus d’informations sur les serveurs d’annuaires pris en charge, consultez la référence du connecteur LDAP générique.
Un 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. Il doit également avoir une connectivité au serveur d’annuaires cible et une connectivité sortante vers login.microsoftonline.com, d'autres services en ligne Microsoft et les domaines Azure . Par exemple, une machine virtuelle Windows Server 2016 hébergée dans Azure IaaS ou derrière un proxy. Le .NET Framework 4.7.2 doit être installé sur ce serveur.
Facultatif : Bien qu’il 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.

Configuration requise pour le cloud

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

Cette fonctionnalité nécessite des licences Microsoft Entra ID P1. Pour trouver la licence qui convient à vos besoins, consultez Comparer les fonctionnalités généralement disponibles de Microsoft Entra ID.
Rôle Administrateur d’identité hybride pour la configuration de l’agent d’approvisionnement.
Rôles Administrateur d’application ou Administrateur d’application cloud pour configurer l’approvisionnement dans le portail Azure ou le Centre d’administration Microsoft Entra.
Le schéma du serveur d’annuaire nécessite des attributs spécifiques pour que chaque utilisateur Microsoft Entra soit approvisionné dans le répertoire LDAP, et ces attributs doivent déjà être renseignés. En particulier, chaque utilisateur doit avoir un numéro unique comme numéro d’id d’utilisateur. Avant de déployer l’agent d’approvisionnement et d’affecter des utilisateurs au répertoire, vous devez générer ce numéro à partir d’un attribut existant sur l’utilisateur ou étendre le schéma Microsoft Entra. Ensuite, vous pouvez renseigner cet attribut pour les utilisateurs concernés. Consultez Extensibilité Graph pour découvrir comment créer des extensions d’annuaire supplémentaires.

Recommandations et limitations supplémentaires

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 le provisionnement d’applications local. Microsoft recommande d’utiliser un agent distinct pour la synchronisation cloud et un agent pour l’approvisionnement d’applications locale.
Pour AD LDS actuellement, 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’annuaires, un mot de passe aléatoire initial peut être défini, mais il n’est pas possible de provisionner le mot de passe d’un utilisateur Microsoft Entra sur un serveur d’annuaire.
L’approvisionnement d’utilisateurs du protocole LDAP vers l’ID Microsoft Entra 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.

Déterminer comment le connecteur MICROSOFT Entra LDAP interagira avec le serveur d’annuaires

Avant de déployer le connecteur sur un serveur d’annuaire existant, vous devez discuter avec l’opérateur de serveur d’annuaire de votre organisation de la façon d’intégrer à son serveur d’annuaires. Les informations à collecter incluent les éléments suivants :

Les informations réseau sur comment se connecter au serveur d'annuaire.
Comment le connecteur doit s’authentifier auprès du serveur d’annuaires.
Schéma que le serveur d’annuaire a sélectionné pour modéliser les utilisateurs.
Les règles de hiérarchie de nom distinctif de base et d’annuaire du contexte d’appellation.
Comment associer des utilisateurs dans le serveur d’annuaire à des utilisateurs dans l’ID Microsoft Entra.
Que devrait-il se passer lorsqu’un utilisateur est hors de portée dans Microsoft Entra ID.

Le déploiement de ce connecteur peut nécessiter des modifications de la configuration du serveur d’annuaire ainsi que des modifications de configuration apportées à l’ID Microsoft Entra. Pour les déploiements impliquant l’intégration de Microsoft Entra ID à un serveur d’annuaire tiers dans un environnement de production, nous recommandons aux clients de travailler avec leur fournisseur de serveurs d’annuaires ou un partenaire de déploiement pour obtenir de l’aide, des conseils et un support pour cette intégration. Cet article utilise les exemples de valeurs suivants pour OpenLDAP.

Paramètre de configuration	Où la valeur est définie	Exemple de valeur
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 via 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=admin,dc=contoso,dc=lab`
mot de passe pour que le connecteur s’authentifie auprès du serveur d’annuaire	Page Connectivité de l’Assistant Configuration
classe d’objets structurels pour un utilisateur dans le serveur d’annuaire	Page Types d’objets de l’Assistant Configuration	`inetOrgPerson`
classes d’objets auxiliaires pour un utilisateur dans le serveur d’annuaire	Mappages d’attributs de la page Approvisionnement du Portail Azure	`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	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
Hiérarchie de dénomination 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éé comme étant immédiatement inférieur à `DC=Contoso,DC=lab`
attributs pour la corrélation des utilisateurs entre l’ID Microsoft Entra et le serveur d’annuaires	Mappages d’attributs de la page Approvisionnement du Portail Azure	`mail`
comportement de désapprovisionnement lorsqu’un utilisateur sort du périmètre dans Microsoft Entra ID	Page Déprovisionnement de l’Assistant Configuration	Supprimer l’utilisateur du serveur d’annuaire

L’adresse réseau d’un serveur d’annuaire est un nom d’hôte et un numéro de port TCP, généralement le port 389 ou 636. Sauf si le serveur d’annuaire est colocalisé avec le connecteur sur le même serveur Windows, ou si vous utilisez la sécurité au niveau du réseau, les connexions réseau du connecteur à un serveur d’annuaire doivent être protégées à l’aide du protocole SSL ou TLS. Le connecteur prend en charge la connexion à un serveur d’annuaires sur le port 389 et l’utilisation du protocole TLS de démarrage pour activer TLS au sein de la session. Le connecteur prend également en charge la connexion à un serveur d’annuaires sur le port 636 pour LDAPS - LDAP via TLS.

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

Un schéma de répertoire spécifie les classes et attributs d’objet qui représentent une entité réelle dans le répertoire. Le connecteur prend en charge la représentation d’un utilisateur avec une classe d’objet structurel, telle que inetOrgPerson, et éventuellement des classes d’objets auxiliaires supplémentaires. Pour que le connecteur puisse approvisionner des utilisateurs dans le serveur d’annuaires, vous devez, lors de la configuration dans le portail Azure, définir des mappages du schéma Microsoft Entra vers tous les attributs obligatoires. Cela inclut les attributs obligatoires de la classe d’objets structurels, les superclasses de cette classe d’objets structurels et les attributs obligatoires de toutes les classes d’objets auxiliaires.

Vous allez probablement également configurer des mappages avec certains des attributs facultatifs de ces classes. Un serveur d’annuaire OpenLDAP avec le schéma POSIX pour prendre en charge l’authentification Linux peut nécessiter un objet pour qu’un nouvel utilisateur ait des attributs comme dans 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 comment les objets de chaque utilisateur se rapportent les uns aux autres et aux objets existants dans le répertoire. Dans la plupart des déploiements, l’organisation a choisi d’avoir une hiérarchie plate dans son serveur d’annuaires, dans laquelle chaque objet d’un utilisateur se trouve immédiatement en dessous d’un objet de base commun. Par exemple, si le nom unique de base du contexte d’affectation de noms dans un serveur d’annuaires est dc=contoso,dc=com un nouvel utilisateur aurait un nom unique comme cn=alice,dc=contoso,dc=com.

Toutefois, certaines organisations peuvent avoir une hiérarchie d’annuaires plus complexe, auquel cas vous devez implémenter les règles lors de la spécification du mappage de nom unique pour le connecteur. Par exemple, un serveur d’annuaires peut s’attendre à ce que les utilisateurs soient dans des unités organisationnelles par service, de sorte qu’un nouvel utilisateur aurait un nom unique comme 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 organisationnelles, les objets intermédiaires attendus par la hiérarchie de règles de serveur d’annuaire doivent déjà exister dans le serveur d’annuaires.

Ensuite, vous devez définir les règles relatives à 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 répertoire LDAP a un nom unique unique pour chaque objet du serveur d’annuaire, mais ce nom unique n’est souvent pas présent pour les utilisateurs dans l’ID Microsoft Entra. Au lieu de cela, une organisation peut avoir un attribut différent, tel que mail ou employeeId, dans son schéma de serveur d’annuaire qui est également présent sur ses utilisateurs dans Microsoft Entra ID. Ensuite, lorsque le connecteur provisionne un nouvel utilisateur dans un serveur d’annuaire, le connecteur peut rechercher s’il existe déjà un utilisateur dans ce répertoire qui a une valeur spécifique de cet attribut, et créer un nouvel utilisateur uniquement dans le serveur d’annuaire si celui-ci n’est pas présent.

Si votre scénario implique la création de nouveaux utilisateurs dans le répertoire LDAP, pas seulement la mise à jour ou la suppression d’utilisateurs existants, vous devez également déterminer comment les systèmes Linux utilisant ce serveur d’annuaire gèrent l’authentification. Certains systèmes peuvent interroger la clé publique OU le certificat SSH d’un utilisateur à partir du répertoire, ce qui peut être approprié pour les utilisateurs qui contiennent déjà des 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 les informations d’identification plus fortes, vous devez définir un mot de passe spécifique à l’application lors de la création d’un utilisateur dans l’annuaire, car l’ID Microsoft Entra ne prend pas en charge l’approvisionnement du mot de passe Microsoft Entra d’un utilisateur.

Enfin, vous devez vous mettre d’accord sur le comportement de déprovisionnement. Lorsque le connecteur est configuré et que l’ID Microsoft Entra est lié entre un utilisateur dans Microsoft Entra ID et un utilisateur dans l’annuaire, soit pour un utilisateur déjà dans l’annuaire, soit pour un nouvel utilisateur, microsoft Entra ID peut provisionner les modifications d’attribut de l’utilisateur Microsoft Entra dans l’annuaire.

Si un utilisateur affecté à l’application est supprimé dans l’ID Microsoft Entra, l’ID Microsoft Entra envoie une opération de suppression au serveur d’annuaires. Vous pouvez également souhaiter que l’ID Microsoft Entra met à jour l’objet dans le serveur d’annuaire lorsqu’un utilisateur ne peut plus utiliser l’application. Ce comportement dépend de l’application qui utilise le serveur d’annuaire, comme de nombreux répertoires, tels qu’OpenLDAP, peuvent ne pas avoir un moyen par défaut d’indiquer que le compte d’un utilisateur est inactivé.

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

Connectez-vous au portail Azure.
Accédez à Applications d’entreprise, puis 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 Approvisionnement de votre application.
Sélectionnez Commencez.
Dans la page Approvisionnement, définissez le mode sur Automatique.

Sous Connectivité locale, sélectionnez Télécharger et installer, puis sélectionnez Accepter le téléchargement des conditions.

Laissez le portail et exécutez le programme d’installation de l’agent d’approvisionnement, acceptez les conditions d’utilisation, puis sélectionnez Installer.
Attendez l’ouverture de l’Assistant Configuration de l’agent d’approvisionnement Microsoft Entra, puis sélectionnez Suivant.
Dans l’étape Sélectionner l’extension, sélectionnez Approvisionnement d’applications sur site, puis sélectionnez Next.
L’agent d’approvisionnement utilise le navigateur web du système d’exploitation pour afficher une fenêtre contextuelle pour vous permettre de vous authentifier auprès de l’ID Microsoft Entra et éventuellement du fournisseur d’identité de votre organisation. Si vous utilisez Internet Explorer comme navigateur sur Windows Server, vous devrez peut-être ajouter des sites web Microsoft à la liste de sites approuvés de votre navigateur pour permettre à JavaScript de s’exécuter correctement.
Communiquez les informations d’identification relatives à un administrateur Microsoft Entra quand 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 terminée, vous pouvez sélectionner Exit, et également fermer le programme d'installation du package du Provisioning Agent.

Configurer l’application ECMA locale

De retour dans le portail, dans la section Connectivité locale, sélectionnez l’agent que vous avez déployé, puis Attribuer les agents.
Laissez cette fenêtre de navigateur ouverte, à mesure que vous effectuez l’étape suivante de la configuration à l’aide de l’Assistant Configuration.

Configurer le certificat hôte du connecteur Microsoft Entra ECMA

Sur windows Server où l’agent d’approvisionnement est installé, sélectionnez l’Assistant Configuration Microsoft ECMA2Host dans le menu Démarrer, puis exécutez 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 avez exécuté l’Assistant, il vous demande de créer un certificat. Laissez le port par défaut 8585, puis 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 san correspond au nom d’hôte.
Sélectionnez Enregistrer.

Note

Si vous avez choisi de générer un nouveau certificat, enregistrez la date d’expiration du certificat pour vous assurer que vous prévoyez de revenir à l’Assistant Configuration et de générer à nouveau le certificat avant son expiration.

Configurer le 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. Utilisez les informations suivantes pour vous guider dans votre configuration.

Générez un jeton secret qui sera utilisé pour authentifier l’ID Microsoft Entra au connecteur. Il doit s’agir de 12 caractères minimum et uniques pour chaque application. Si vous n’avez pas encore de générateur de secrets, vous pouvez utiliser une commande PowerShell telle que la commande 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 Propriétés, renseignez les zones avec les valeurs spécifiées dans le tableau qui suit l’image et sélectionnez Suivant.

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 asynchrone automatique (minutes)	120
Jeton secret	Entrez votre jeton secret ici. Il doit s’agir de 12 caractères minimum.
Extension DLL	Pour le connecteur LDAP générique, sélectionnez Microsoft.IAM.Connector.GenericLdap.dll.

Dans la page Connectivité, vous allez configurer la façon dont l’hôte du connecteur ECMA communique avec le serveur d’annuaire et définit certaines des options de configuration. Renseignez les zones avec les valeurs spécifiées dans le tableau qui suit l’image et sélectionnez Suivant. Lorsque vous sélectionnez suivant, le connecteur interroge le serveur d’annuaire pour sa configuration.

Propriété	Description
Hôte	Nom d’hôte où se trouve le serveur LDAP. Cet exemple utilise `APP3` comme exemple de nom d’hôte.
Port	Numéro de port TCP. Si le serveur d’annuaires est configuré pour LDAP via SSL, utilisez le port 636. Pour `Start TLS`, ou si vous utilisez la sécurité au niveau du réseau, utilisez le port 389.
Délai de connexion	180
Liaison	Cette propriété spécifie comment le connecteur s’authentifie auprès du serveur d’annuaires. Avec le paramètre `Basic`, ou avec le paramètre `SSL` ou `TLS` et aucun certificat client configuré, le connecteur envoie une liaison simple LDAP 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és, le connecteur envoie une liaison SASL LDAP `EXTERNAL` pour s’authentifier auprès d’un certificat client.
Nom d’utilisateur	Comment le connecteur ECMA s’authentifie auprès du serveur d’annuaires. Dans cet exemple, `cn=admin,dc=contoso,dc=lab`
Mot de passe	Le mot de passe de l'utilisateur avec lequel le connecteur ECMA s'authentifie auprès du serveur d'annuaire.
Domaine/Royaume	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 uniquement si vous avez sélectionné `SSL` ou `TLS` comme option de liaison.
Alias d’attributs	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 pendant la détection de schéma et le connecteur a besoin d’aide pour identifier ces attributs. Par exemple, si le serveur d’annuaire ne publie pas `userCertificate;binary` et que vous souhaitez approvisionner cet attribut, la chaîne suivante doit être entrée dans la zone 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 des attributs opérationnels	Cochez la case `Include operational attributes in schema` pour inclure également les attributs créés par le serveur d’annuaires. Ceux-ci incluent des attributs tels que l’heure de création et de dernière mise à jour de l’objet.
Inclure des attributs extensibles	Cochez la case `Include extensible attributes in schema` si des objets extensibles (RFC4512/4.3) sont utilisés dans le serveur d’annuaires. L’activation de cette option permet à chaque attribut d’être utilisé sur tous les objets. La sélection de cette option rend le schéma très volumineux, sauf si le répertoire connecté utilise cette fonctionnalité, la recommandation consiste à conserver l’option non sélectionnée.
Autoriser la sélection manuelle de l’ancre	Laissez la case non activée.

Note

Si vous rencontrez un problème lors de la tentative de connexion et que vous ne pouvez pas passer à la page Global, vérifiez que le compte de service dans le serveur d’annuaires est activé.

Dans la page Global, vous allez configurer le nom unique du journal des modifications delta, si nécessaire, et d’autres fonctionnalités LDAP. La page est préremplie avec les informations fournies par le serveur LDAP. Passez en revue les valeurs affichées, puis sélectionnez Suivant.

Propriété	Description
Mécanismes SASL pris en charge	La section supérieure affiche les informations fournies par le serveur lui-même, y compris la liste des mécanismes SASL.
Détails du certificat 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 numérique concernent le serveur d’annuaire approprié.
Fonctionnalités obligatoires trouvées	Le connecteur vérifie également que les contrôles obligatoires sont présents dans le DSE racine. Si ces contrôles ne sont pas répertoriés, un avertissement est présenté. Certains répertoires LDAP ne répertorient pas toutes les fonctionnalités du DSE racine et il est possible que le connecteur fonctionne sans problème même si un avertissement est présent.
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 d’appellation utilisé par le journal des modifications différentielles, par exemple, cn=changelog. Cette valeur doit être spécifiée pour pouvoir effectuer l’importation delta. Si vous n’avez pas besoin d’implémenter l’importation delta, ce champ peut être vide.
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 modifications de mot de passe.
Noms de partitions	Dans la liste des partitions supplémentaires, il est possible d’ajouter des espaces de noms supplémentaires non détectés automatiquement. Par exemple, ce paramètre peut être utilisé si plusieurs serveurs composent un cluster logique, qui doit tous être importé en même temps. 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 importer depuis différents serveurs et est davantage configuré sur la page Configurer des partitions et des hiérarchies.

Sur la page Partitions, conservez la valeur par défaut et sélectionnez Suivant.

Dans la page Exécuter des profils, vérifiez que la case Exporter et la case Importation complète sont toutes les deux cochées. Sélectionnez ensuite Suivant.

Propriété	Description
Exporter	Exécutez le profil qui exporte des données vers le serveur d’annuaire LDAP. Ce profil d’exécution est requis.
Importation complète	Exécutez le profil qui importe toutes les données à partir de sources LDAP spécifiées précédemment. Ce profil d’exécution est requis.
Importation d’écart	Exécutez le profil qui importe uniquement les modifications du protocole LDAP depuis la dernière importation complète ou delta. Activez ce profil d’exécution uniquement si vous avez confirmé que le serveur d’annuaires répond aux exigences nécessaires. Pour plus d’informations, consultez la référence du connecteur LDAP générique .

Sur la page Export, laissez les valeurs par défaut inchangées et sélectionnez Suivant.
À la page Importation complète, conservez les mêmes valeurs par défaut et cliquez sur Suivant.
Sur la page DeltaImport, si elle est présente, laissez les valeurs par défaut inchangées et sélectionnez Suivant.

À la page Types d’objets, renseignez les zones et sélectionnez Suivant.

Propriété	Description
Objet cible	Cette valeur est la classe d’objet structurel d’un utilisateur dans le serveur d’annuaire LDAP. Utilisez `inetOrgPerson`et ne spécifiez pas de classe d’objet auxiliaire dans ce champ. Si le serveur d’annuaire nécessite des classes d’objets auxiliaires, elles sont configurées avec les mappages d’attributs dans le portail Azure.
Ancrage	Les valeurs de cet attribut doivent être uniques pour chaque objet dans le répertoire cible. Le service d’approvisionnement Microsoft Entra interroge l’hôte du connecteur ECMA à l’aide de cet attribut après le cycle initial. Utilisez généralement le nom distingué, qui 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.
Attribut de requête	Cet attribut doit être identique à l’ancre.
DN	Nom unique de l’objet cible. Conservez `-dn-`.
Généré automatiquement	non cochée

L’hôte ECMA découvre les attributs pris en charge par le répertoire cible. Vous pouvez choisir les attributs que vous souhaitez exposer à l’ID Microsoft Entra. Ces attributs peuvent ensuite être configurés dans le portail Azure pour l’approvisionnement. Dans la page Sélectionner des attributs, ajoutez tous les attributs dans la liste déroulante, un par un, requis en tant qu’attributs obligatoires ou que vous souhaitez approvisionner à partir de l’ID Microsoft Entra.
La liste déroulante Attribut affiche 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.

Vérifiez que la case à cocher Treat as single value n'est pas cochée pour l'attribut objectClass et, si userPassword est en cours de définition, qu'elle soit soit non sélectionnable, soit cochée pour l'attribut userPassword.

Configurez la visibilité pour les attributs suivants.

Attribut	Traiter comme une valeur unique
_distinguishedName
-dn-
export_password
cn	Y
gidNumber
homeDirectory
courrier	Y
objectClass
sn	Y
uid	Y
uidNumber
mot de passe de l'utilisateur	Y

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

Sur la page Déprovisionnement, vous pouvez spécifier si vous souhaitez que Microsoft Entra ID supprime les utilisateurs de l’annuaire lorsqu’ils ne sont plus dans le périmètre 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 sur la page précédente ne seront pas disponibles pour sélectionner sur la page de déprovisionnement.

Note

Si vous utilisez Définir la valeur d’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 peut lire à partir du serveur d’annuaires

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

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ésente et en cours d’exécution. Si elle n’est pas en cours d’exécution, sélectionnez Démarrer.
Si vous avez récemment démarré le service et que vous avez de nombreux objets utilisateur dans le serveur d’annuaire, attendez plusieurs minutes que le connecteur établisse une connexion avec le serveur d’annuaire.
Sur le serveur exécutant l’hôte du connecteur Microsoft Entra ECMA, lancez PowerShell.
Accédez au dossier où 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 ce répertoire, comme indiqué, et fournissez en tant qu’arguments le nom du connecteur et la valeur ObjectTypePathcache. Si votre hôte de connecteur n'écoute pas sur le port TCP 8585, vous devrez peut-être fournir l'argument -Port également. 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 à ces valeurs que vous avez configurées dans l’Assistant Configuration.
Si le script affiche la sortie False, le connecteur n’a pas vu d’entrées dans le serveur d’annuaire source pour les utilisateurs existants. S’il s’agit d’une nouvelle installation de serveur d’annuaires, ce comportement doit être attendu et vous pouvez continuer à la section suivante.
Toutefois, si le serveur d’annuaire contient déjà un ou plusieurs utilisateurs, mais que le script s’affiche 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. Attendez plusieurs minutes que l’hôte du connecteur termine la lecture des objets à partir du serveur d’annuaire existant, puis réexécutez le script. Si la sortie continue d’être False, vérifiez la configuration de votre connecteur et les autorisations dans le serveur d’annuaires permettent au connecteur de lire les utilisateurs existants.

Tester la connexion de Microsoft Entra ID à l’hôte du connecteur

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

Note

Si la fenêtre a expiré, vous devez sélectionner à nouveau l’agent.
1. Connectez-vous au portail Azure.
2. Accédez à Applications d’entreprise, puis à l’Application ECMA locale.
3. Sélectionnez Approvisionnement.
4. Si Démarrer s’affiche, remplacez le mode par Automatique, dans la section Connectivité sur site, sélectionnez l’agent que vous venez de déployer et choisissez Affecter des agents, puis attendez 10 minutes. Sinon, accédez à Modifier l’approvisionnement.
Sous 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 sur lequel l’hôte ECMA est installé.

Propriété Valeur

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

Note

Si vous venez d’affecter l’agent à l’application, attendez 10 minutes pour que l’inscription se termine. Le test de connectivité ne fonctionnera pas tant que l’inscription n’est pas terminée. Forcer l’inscription de l’agent à terminer en redémarrant l’agent d’approvisionnement sur votre serveur peut accélérer le processus d’inscription. Accédez à votre serveur, recherchez services dans la barre de recherche Windows, identifiez la Microsoft Entra Connect Provisioning Agent service, sélectionnez le service avec le bouton droit, puis redémarrez.
Sélectionnez Connexion de test 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 l’approvisionnement, sélectionnez Enregistrer.

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

Étendre le schéma Microsoft Entra

Si votre serveur d’annuaire nécessite des attributs supplémentaires qui ne font pas partie du schéma Microsoft Entra par défaut pour les utilisateurs, lors de l’approvisionnement, vous pouvez configurer pour fournir des valeurs de ces attributs à partir d’une constante, d’une expression transformée à partir d’autres attributs Microsoft Entra ou en étendant le schéma Microsoft Entra.

Si le serveur d’annuaire exige que les utilisateurs aient un attribut, tel que uidNumber pour le schéma OPENLDAP POSIX, et que cet attribut ne fait pas déjà partie de votre schéma Microsoft Entra pour un utilisateur et doit être unique pour chaque utilisateur, vous devez générer cet attribut à partir d’autres attributs de l’utilisateur via une expression , ou utilisez la fonctionnalité d’extension d’annuaire pour ajouter cet attribut en tant qu’extension.

Si vos utilisateurs proviennent des services de domaine Active Directory et disposent de l’attribut dans cet annuaire, vous pouvez utiliser Microsoft Entra Connect ou microsoft Entra Connect cloud sync. Cela configure l’attribut pour qu’il soit synchronisé entre Active Directory Domain Services et Microsoft Entra ID, ce qui le rend disponible pour l’approvisionnement sur d’autres systèmes.

Si vos utilisateurs proviennent de Microsoft Entra ID, vous devez définir une extension d’annuaire pour chaque nouvel attribut à stocker sur un utilisateur. 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 configurerez le mappage entre les attributs de l'utilisateur Microsoft Entra et les attributs que vous avez sélectionnés précédemment dans l'assistant de configuration de l'hôte ECMA. Plus tard, lorsque le connecteur crée un objet dans un serveur d’annuaire, les attributs utilisateur Microsoft Entra sont 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 la configuration.
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 en tant qu’espace réservé.
Pour vérifier que le schéma du serveur d’annuaire est disponible dans l’ID Microsoft Entra, cochez la case Afficher les options avancées et cochez Modifier la liste d’attributs pour ScimOnPremises. Vérifiez que tous les attributs sélectionnés dans l’Assistant de configuration sont répertorié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 d’un répertoire doit avoir un nom unique unique. Vous pouvez spécifier comment le connecteur doit construire un nom unique à l’aide d’un mappage d’attributs. Sélectionnez Ajouter un mappage. Utilisez les valeurs suivantes pour créer le mappage, en modifiant les noms uniques de l’expression pour qu’ils correspondent à celui de l’unité organisationnelle ou d’un autre conteneur dans votre répertoire cible.
- Type de mappage : expression
- Expression : 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 lors de la création d’objets
Si le serveur d’annuaire requiert plusieurs valeurs de classe d’objet structurelle ou des valeurs de classe d’objet auxiliaires, à fournir dans l’attribut objectClass, ajoutez un mappage à cet attribut. Pour ajouter un mappage pour objectClass, sélectionnez Ajouter un nouveau mappage. Utilisez les valeurs suivantes pour créer le mappage, en modifiant les noms de classe d’objet dans l’expression pour qu’ils correspondent à celui du schéma du répertoire cible.
- Type de mappage : expression
- Expression, s’il s’agit de l’approvisionnement 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 lors de la création d’objets

Pour chacun des mappages du tableau suivant pour votre serveur d’annuaires, sélectionnez Ajouter un nouveau mappage, puis 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. En savoir plus sur le mappage d’attributs ici.

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 uidNumberunique. En règle générale, le homeDirectory est défini par une expression dérivée de l’ID utilisateur de l’utilisateur. Par exemple, si la uid d’un utilisateur est générée 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 fonction de votre cas d’usage, vous souhaiterez peut-être que tous les utilisateurs fassent partie du même groupe, afin d'attribuer gidNumber à partir d'une constante.

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

Ajoutez un mappage à urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword qui définit un mot de passe aléatoire initial pour l’utilisateur.
Sélectionnez Enregistrer.

S'assurer que les utilisateurs à approvisionner dans le répertoire possèdent les attributs requis.

S’il existe des personnes qui ont des comptes d’utilisateur existants dans l’annuaire LDAP, vous devez vous assurer que la représentation utilisateur Microsoft Entra a les attributs requis pour la correspondance.

Si vous envisagez de créer des utilisateurs dans le répertoire LDAP, vous devez vous assurer que les représentations Microsoft Entra de ces utilisateurs ont les attributs sources requis par le schéma utilisateur du répertoire cible. Chaque utilisateur nécessite un uid unique et un uidNumberunique.

Si vos utilisateurs proviennent des services de domaine Active Directory et disposent de l’attribut dans cet annuaire, vous pouvez utiliser microsoft Entra Connect ou microsoft Entra Connect cloud sync pour configurer que l’attribut doit être synché à partir des services de domaine Active Directory vers l’ID Microsoft Entra, afin qu’il soit disponible pour l’approvisionnement 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.

Confirmation des utilisateurs via PowerShell

Une fois que vous avez mis à jour les utilisateurs dans Microsoft Entra ID, vous pouvez utiliser les applets de commande Microsoft Graph PowerShell pour vérifier automatiquement que les utilisateurs disposent de tous les attributs requis.

Par exemple, supposons que le processus de provisionnement requiert des utilisateurs ayant trois attributs : DisplayName,surname et extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Ce troisième attribut est utilisé pour contenir la uidNumber. Vous pouvez utiliser l’applet de commande Get-MgUser pour récupérer chaque utilisateur et vérifier si les attributs requis sont présents. Notez que l’applet de commande Graph v1.0 Get-MgUser, par défaut, ne retourne aucun attribut d’extension d’annuaire d’un utilisateur, sauf si les attributs sont spécifiés dans la requête comme l’une des propriétés à retourner.

Cette section explique comment interagir avec Microsoft Entra ID en utilisant les cmdlets de Microsoft Graph PowerShell.

La première fois que votre organisation utilise ces applets de commande pour ce scénario, vous devez être dans un rôle d’administrateur général pour permettre à Microsoft Graph PowerShell d’être utilisé dans votre locataire. Les interactions suivantes peuvent utiliser un rôle à privilèges inférieurs, par exemple :

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

Ouvrez PowerShell.
Si vous n’avez pas les modules Microsoft Graph PowerShell déjà installés, installez le module Microsoft.Graph.Users et d’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.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

Créez la liste des utilisateurs et les attributs à vérifier.

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

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

Interrogez le répertoire pour chacun des utilisateurs.

$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" } }
}

Collecter des utilisateurs existants à partir du répertoire LDAP

Identifiez quels utilisateurs de cet annuaire sont concernés par l’authentification Linux. Ce choix dépend de la configuration de votre système Linux. Pour certaines configurations, tout utilisateur qui existe dans un répertoire LDAP est un utilisateur valide. D’autres configurations peuvent obliger l’utilisateur à avoir un attribut particulier ou à être membre d’un groupe dans ce répertoire.
Exécutez une commande qui récupère ce sous-ensemble d’utilisateurs de votre répertoire LDAP dans un fichier CSV. Vérifiez que la sortie inclut les attributs des utilisateurs utilisés pour la correspondance avec l’ID Microsoft Entra. Par exemple, ces attributs sont l’ID d’employé, le nom du compte ou uidet l’adresse e-mail.
Si nécessaire, transférez le fichier CSV qui contient la liste des utilisateurs vers un système avec les applets de commande Microsoft Graph PowerShell installées.
Maintenant que vous avez une liste de tous les utilisateurs obtenus à partir de l’annuaire, vous devez faire correspondre ces utilisateurs à partir de l’annuaire avec des utilisateurs dans 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.

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

Ouvrez PowerShell.
Si vous n’avez pas les modules Microsoft Graph PowerShell déjà installés, installez le module Microsoft.Graph.Users et d’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 avez utilisé cette commande, vous devrez peut-être donner votre consentement pour autoriser les outils de ligne de commande Microsoft Graph à disposer de ces autorisations.
Lisez la liste des utilisateurs obtenus à partir du magasin de données de l’application dans la session PowerShell. Si la liste des utilisateurs se trouvait dans un fichier CSV, vous pouvez utiliser l’applet de commande PowerShell Import-Csv et fournir le nom du fichier de la section précédente en tant qu’argument.

Par exemple, si le fichier obtenu à partir de SAP Cloud Identity Services est nommé 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
```
Pour obtenir un autre exemple si vous utilisez une base de données ou un répertoire, si le fichier est nommé users.csv et situé 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, le mappage par défaut est l’attribut SAP SCIM userName avec l’attribut Microsoft Entra ID userPrincipalName:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Pour un autre exemple si vous utilisez une base de données ou un répertoire, vous pouvez avoir des utilisateurs dans une base de données où la valeur de la colonne nommée EMail est la même valeur que 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. Il interroge Microsoft Entra ID pour localiser un utilisateur disposant d’un attribut avec une valeur correspondante pour chaque enregistrement dans le fichier source. S’il existe de nombreux utilisateurs dans le fichier obtenu à partir de la source SAP Cloud Identity Services, de la base de données ou du répertoire, ce script peut prendre plusieurs minutes. Si vous n’avez pas d’attribut dans l’ID Microsoft Entra qui possède la valeur requise et que vous devez utiliser une contains ou une autre expression de filtre, vous devrez personnaliser ce script ainsi que celui mentionné à l’étape 11 ci-dessous pour utiliser une expression de filtre différente.

$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 }
}

Affichez 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 se trouver dans l’ID Microsoft Entra, 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."

Une fois le script terminé, il signalera une erreur si des enregistrements de la source de données n’ont pas été trouvés dans Microsoft Entra ID. Si tous les enregistrements des utilisateurs du magasin de données de l’application ne peuvent pas être situés en tant qu’utilisateurs dans l’ID Microsoft Entra, vous devez examiner les enregistrements qui ne correspondent pas et pourquoi.

Par exemple, l’adresse e-mail d’une personne et userPrincipalName a peut-être été modifiée dans l’ID Microsoft Entra sans que leur propriété de mail correspondante soit mise à jour dans la source de données de l’application. Ou bien, l’utilisateur a peut-être déjà quitté l’organisation, mais se trouve toujours dans la source de données de l’application. Ou il peut y avoir un compte fournisseur ou super-administrateur dans la source de données de l’application qui ne correspond à aucune personne spécifique dans l’ID Microsoft Entra.
S’il y avait des utilisateurs qui n’ont pas pu se trouver dans l’ID Microsoft Entra ou qui n’étaient pas actifs et en mesure de se connecter, mais 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 l’annuaire, vous devez mettre à jour l’application, la règle correspondante, 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 l’option de création d’utilisateurs dans l’ID Microsoft Entra, vous pouvez créer des utilisateurs en bloc à l’aide de l’une ou l’autre des options suivantes :
- Un fichier CSV, comme décrit dans Création en bloc d’utilisateurs dans le centre d’administration Microsoft Entra
- Avec la cmdlet New-MgUser
Assurez-vous que ces nouveaux utilisateurs sont remplis avec les attributs requis pour que l’ID Microsoft Entra les corresponde ultérieurement aux utilisateurs existants de l’application, ainsi que les attributs requis par l’ID Microsoft Entra, notamment userPrincipalName, mailNickname et displayName. La userPrincipalName doit être unique parmi tous les utilisateurs du répertoire.

Par exemple, vous pouvez avoir des utilisateurs dans une base de données où la valeur de la colonne nommée EMail est la valeur que vous souhaitez utiliser comme nom d’utilisateur principal De Microsoft Entra, la valeur de la colonne Alias contient le surnom de messagerie Microsoft Entra ID et la valeur de la colonne Full name contient le nom d’affichage 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 dans SAP Cloud Identity Services, la base de données ou le répertoire qui ne correspondent pas aux utilisateurs dans Microsoft Entra ID. Notez que vous devrez peut-être modifier ce script pour ajouter des attributs Microsoft Entra supplémentaires nécessaires à votre organisation, ou si le $azuread_match_attr_name n’est ni mailNickname ni userPrincipalName, afin de 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é des utilisateurs manquants à l’ID Microsoft Entra, réexécutez le script à l’étape 7. Puis exécutez 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 à l’application dans l’ID Microsoft Entra

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 êtes connecté à l’aide d’un rôle Administrateur d’identité hybride, vous devez vous déconnecter et vous connecter avec un compte qui a au moins le rôle Administrateur d’application pour cette section. Le rôle Administrateur d’identité hybride n’a pas les autorisations nécessaires pour affecter des utilisateurs aux applications.

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

Si vous ne souhaitez pas encore mettre à jour les utilisateurs existants dans l’annuaire LDAP, sélectionnez un utilisateur de test à partir de l’ID Microsoft Entra qui a les attributs requis et sera approvisionné sur le serveur d’annuaire.

Vérifiez que l’utilisateur sélectionne toutes les propriétés qui seront mappées aux attributs requis du schéma du serveur d’annuaire.
Dans le portail Azure, sélectionnez applications d’entreprise.
Sélectionnez l’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 un utilisateur à droite et sélectionnez le bouton Sélectionner.
Sélectionnez Affecter.

Tester l’approvisionnement

Maintenant que vos attributs sont mappés et qu’un utilisateur initial est affecté, 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 ECMA locale.
Sur la gauche, sélectionnez Approvisionnement.
Sélectionnez Approvisionner à la demande.
Recherchez l’un de vos utilisateurs de test, puis sélectionnez Provision.
Après plusieurs secondes, le message Utilisateur créé avec succès dans le système cible s'affichera, avec une liste des attributs de l'utilisateur. Si une erreur s’affiche à la place, consultez résolution des erreurs d’approvisionnement.

Démarrer l’approvisionnement des utilisateurs

Une fois le test de l’approvisionnement à la demande réussi, ajoutez les utilisateurs restants. Pour en savoir plus sur la création en bloc d’attributions de rôles d’application à l’aide de New-MgServicePrincipalAppRoleAssignedTo, voir pour gérer les utilisateurs existants d'une application dans Microsoft Entra ID.

Dans le portail Azure, sélectionnez l’application.
À gauche, sous Gérer, sélectionnez Utilisateurs et groupes.
Vérifiez que tous les utilisateurs sont affectés au rôle d’application.
Revenez à la page de configuration du provisionnement.
Vérifiez que l’étendue est définie sur les seuls utilisateurs et groupes attribués, activez l’approvisionnement, puis sélectionnez Enregistrer.
Patientez plusieurs minutes pour que l’approvisionnement démarre. Cela peut prendre jusqu’à 40 minutes. Une fois le travail d’approvisionnement terminé, comme décrit dans la section suivante,

Résolution des erreurs d’approvisionnement

Si une erreur s’affiche, sélectionnez Afficher les journaux d’approvisionnement. Recherchez dans le journal une ligne dans laquelle l’état est Échec, puis sélectionnez 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 & Recommandations.

Si le message d’erreur de dépannage inclut qu’une valeur objectClass est invalid per syntax, vérifiez que le mappage d’attributs d’approvisionnement à l’attribut objectClass inclut uniquement les noms des 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 suspendre l’approvisionnement sur cette application, dans la page de configuration du provisionnement, vous pouvez modifier l’état d’approvisionnement en Désactivé, puis sélectionner Enregistrer. Cette action empêche que le service d’approvisionnement s’exécute à l’avenir.

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

Après avoir attendu, vérifiez le serveur d’annuaire pour vous assurer que les utilisateurs sont approvisionnés. La requête que vous effectuez sur le serveur d’annuaire dépend des commandes que votre serveur d’annuaire fournit.

Les instructions suivantes montrent comment vérifier OpenLDAP sur Linux.

Ouvrez une fenêtre de terminal avec un interpréteur de commandes sur le système avec OpenLDAP.
Tapez 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 obtenu inclut les utilisateurs approvisionnés à partir de l’ID Microsoft Entra.

Étapes suivantes

Pour plus d’informations sur le fonctionnement du service d’approvisionnement, son fonctionnement et les questions fréquemment posées, consultez Automatiser l’approvisionnement et le déprovisionnement d’utilisateurs pour les applications SaaS avec Microsoft Entra ID et architecture d’approvisionnement d’applications locales.

Partager via

Configuration de l’ID Microsoft Entra pour approvisionner des utilisateurs dans un répertoire LDAP pour l’authentification Linux

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

Conditions préalables locales

Configuration requise pour le cloud

Recommandations et limitations supplémentaires

Déterminer comment le connecteur MICROSOFT Entra LDAP interagira avec le serveur d’annuaires

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

Configurer l’application ECMA locale

Configurer le certificat hôte du connecteur Microsoft Entra ECMA

Configurer le connecteur LDAP générique

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

Tester la connexion de Microsoft Entra ID à l’hôte du connecteur

Étendre le schéma Microsoft Entra

Configurer le mappage d’attributs

S'assurer que les utilisateurs à approvisionner dans le répertoire possèdent les attributs requis.

Confirmation des utilisateurs via PowerShell

Collecter des utilisateurs existants à partir du répertoire LDAP

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

Affecter des utilisateurs à l’application dans l’ID Microsoft Entra

Tester l’approvisionnement

Démarrer l’approvisionnement des utilisateurs

Résolution des erreurs d’approvisionnement

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

Étapes suivantes

Commentaires

Ressources supplémentaires