Configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP pour l’authentification Linux

Article
02/13/2024

La documentation suivante est un tutoriel montrant comment régir l’accès à un système Linux. Cela est implémenté par Microsoft Entra approvisionnant des utilisateurs dans un répertoire LDAP local approuvé par ce système Linux, afin que ces utilisateurs puissent ensuite se connecter à un système Linux qui s’appuie sur ce répertoire LDAP pour l’authentification utilisateur. Et lorsqu’un utilisateur est supprimé de Microsoft Entra ID, il ne peut plus se connecter à un système Linux.

Remarque

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 (Pluggable Authentication Modules) pour l’identification et l’authentification des utilisateurs. Les machines virtuelles Linux dans Azure ou qui sont compatibles avec Azure Arc doivent plutôt être intégrées à l’authentification Microsoft Entra. Vous pouvez désormais utiliser Microsoft Entra ID comme plateforme d’authentification principale et autorité de certification pour établir une connexion SSH avec une machine virtuelle Linux en tirant parti de Microsoft Entra ID et de l’authentification basée sur un certificat OpenSSH, tel que décrit dans Connexion à une machine virtuelle Linux dans Azure à l’aide de Microsoft Entra ID et OpenSSH.

Pour d’autres scénarios impliquant l’approvisionnement d’utilisateurs dans des annuaires LDAP, autres que pour l’authentification Linux, consultez l’article sur la Configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP.

Conditions préalables pour l’approvisionnement d’utilisateurs dans un annuaire 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 autres systèmes POSIX pour l’authentification des utilisateurs.

Diagramme de l’architecture d’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'annuaire pris en charge, consultez la Référence du connecteur LDAP générique.
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é au serveur d’annuaire cible et une connectivité sortante à login.microsoftonline.com et d’autres services Microsoft Online Services et 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 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.

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.
Le rôle d’administrateur d’identités hybrides pour configurer l’agent d’approvisionnement.
Les rôles d’administrateur d'application ou d’administrateur d’application cloud pour configurer l’approvisionnement dans le Portail Azure ou le centre d’administration Microsoft Entra.
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. Chaque utilisateur est notamment tenu d’avoir un numéro unique comme numéro d’identification de l’utilisateur. Avant de déployer l’agent d’approvisionnement et d’affecter des utilisateurs à l’annuaire, vous devez générer ce numéro à partir d’un attribut existant sur l’utilisateur, ou étendre le schéma Microsoft Entra et remplir cet attribut sur l’étendue des utilisateurs. 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. Par conséquent, vous devez désactiver la stratégie de mot de passe pour AD LDS ou bien provisionner 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’attribuer le mot de passe d’un utilisateur Microsoft Entra sur un serveur d’annuaire.
L’attribution des utilisateurs de LDAP vers Microsoft Entra ID n’est pas pris en charge.
Le provisionnement de groupes et d’appartenances des utilisateurs sur un serveur d’annuaire n’est pas pris en charge.

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 s’appuie sur les valeurs d’exemples suivants 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=admin,dc=contoso,dc=lab`
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	`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 noms requise par le serveur d’annuaire	Mappages d’attributs de la page Approvisionnement du Portail Azure	Définissez le nom de domaine de l’utilisateur créé juste au-dessous de `DC=Contoso,DC=lab`.
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	`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 attribuer 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. Un serveur d’annuaire OpenLDAP doté du schéma POSIX peut exiger qu’un objet destiné à un nouvel utilisateur ait des attributs, comme dans l’exemple suivant, afin de prendre en charge l’authentification Linux.

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 Azure AD. 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 systèmes Linux qui utilisent ce serveur d’annuaire vont gérer l’authentification. Certains systèmes 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 identifiants 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.

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

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 exécutez le programme d’installation de l’agent d’approvisionnement, acceptez les conditions d’utilisation du service, puis sélectionnez Installer.
Attendez que l’Assistant Configuration de l’agent d’approvisionnement Microsoft Entra s’affiche, 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 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 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 : `cn=admin,dc=contoso,dc=lab`
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 le 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 annuaires LDAP ne répertorient pas toutes les fonctionnalités de la DSE racine. Il est donc 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. 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 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 non 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. Utilisez `inetOrgPerson` et 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. Utilisez généralement le nom unique, qui peut être sélectionné en tant que `-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.
DN	Nom unique (distinguishedName) 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 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.

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.

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 ce répertoire et fournissez comme arguments le nom du connecteur et la valeur cache pour ObjectTypePath. 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 avait 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

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 attribué 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 ci-dessous pour créer le mappage, en remplaçant les noms uniques dans l’expression par ceux de l’unité d’organisation ou d’un autre conteneur dans votre annuaire 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 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 ajouter un mappage de objectClass, sélectionnez Ajouter un nouveau mappage. Utilisez les valeurs ci-dessous pour créer le mappage, en remplaçant les noms de classes d’objets dans l’expression par ceux du schéma de l’annuaire cible.
- Type de mappage : expression
- 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

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 provisionnez dans un annuaire existant avec des utilisateurs existants, vous devez modifier le mappage de l’attribut qui est 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 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
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, ce qui définit un mot de passe aléatoire initial pour l’utilisateur.
Sélectionnez Enregistrer.

Vérifier que les utilisateurs à approvisionner dans l’annuaire disposent d’attributs requis

Si certains utilisateurs ont des 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. Chaque utilisateur nécessite un uid unique et un uidNumber unique.

Confirmation des utilisateurs via PowerShell

Une fois les utilisateurs mis à jour dans Microsoft Entra ID, vous pouvez utiliser les cmdlets Microsoft Graph PowerShell pour vérifier automatiquement que les utilisateurs possèdent tous les attributs requis.

Par exemple, supposons que votre approvisionnement exige que les utilisateurs soient associés à trois attributs DisplayName,surname et extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Ce troisième attribut sera utilisé pour contenir le uidNumber. 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.

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.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

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

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

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

Interrogez l’annuaire 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" } }
}

Collectez les utilisateurs existants à partir de l’annuaire LDAP

Identifiez les utilisateurs de l’annuaire susceptibles d'être des utilisateurs de l’application via l’authentification Linux. Ce choix dépend de la configuration de votre système Linux. Selon certaines configurations, tout utilisateur qui existe dans un annuaire LDAP est un utilisateur valide. D’autres configurations 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 une commande qui récupère ce sous-ensemble d’utilisateurs à partir de votre annuaire LDAP vers un fichier CSV. Vérifiez que la sortie comprend les attributs d’utilisateurs qui seront utilisés pour la mise en correspondance avec Microsoft Entra ID. Parmi ces attributs, on peut citer l’ID employé, le nom de compte ou uid, et l'adresse e-mail.
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 à partir de l’annuaire, vous devez faire correspondre ces utilisateurs de l’annuaire avec ceux 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.

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."

Affectez des utilisateurs à l’application dans Microsoft Entra ID

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 le 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. 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.

Si vous ne souhaitez pas encore mettre à jour les utilisateurs existants dans l’annuaire LDAP, sélectionnez un utilisateur test de Microsoft Entra ID qui possède les attributs requis et qui sera fourni au serveur d'annuaire.

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

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 indiquent comment vérifier OpenLDAP sur Linux.

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.

Étapes suivantes

Pour plus d’informations sur le service de provisionnement, son fonctionnement et les questions fréquentes (FAQ), consultez Automatiser le provisionnement et le dé-provisionnement des utilisateurs pour les applications SaaS avec Microsoft Entra ID et Architecture locale pour l’approvisionnement d’applications.

Partager via

Configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP pour l’authentification Linux

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

Conditions préalables locales

Conditions préalables requises du cloud

Plus de recommandations et restrictions

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

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

Configurer l’application ECMA locale

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

Configurer le 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

Configurer le mappage d’attributs

Vérifier que les utilisateurs à approvisionner dans l’annuaire disposent d’attributs requis

Confirmation des utilisateurs via PowerShell

Collectez les utilisateurs existants à partir de l’annuaire LDAP

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

Affectez des utilisateurs à l’application dans Microsoft Entra ID

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