Migration d’utilisateurs vers l’ID externe Microsoft Entra

Dans ce guide, vous allez découvrir les principes fondamentaux de la migration des utilisateurs et des informations d’identification de votre fournisseur d’identité actuel, y compris Azure AD B2C, vers l’ID externe Microsoft Entra. Ce guide couvre différentes solutions que vous pouvez utiliser en fonction de votre configuration actuelle. Avec chacune de ces approches, vous devez écrire une application ou un script qui utilise l’API Microsoft Graph pour créer des comptes d’utilisateur dans l’ID externe.

Important

À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez Azure AD B2C est-il toujours disponible pour l’achat ? dans notre FAQ.

Conditions préalables

Avant de commencer à migrer des utilisateurs vers un ID externe, vous avez besoin des éléments suivants :

• Un locataire externe. Pour en créer un, choisissez parmi les méthodes suivantes :
  • Utilisez l’extension Microsoft Entra External ID pour configurer un locataire externe directement dans Visual Studio Code.
  • Créer un nouveau locataire externe dans le Centre d’administration Microsoft Entra.

Préparation : nettoyage d’annuaire

Avant de commencer votre processus de migration utilisateur, vous devez prendre le temps de nettoyer les données dans votre répertoire de fournisseur d’identité hérité. Cela vous permet de vous assurer que vous migrez uniquement les données dont vous avez besoin et facilitez le processus de migration.

• Identifiez l’ensemble d’attributs utilisateur à stocker dans l’ID externe et migrez uniquement ce dont vous avez besoin. Si nécessaire, vous pouvez créer des attributs personnalisés dans l’ID externe pour stocker plus de données sur un utilisateur.
• Si vous migrez à partir d’un environnement avec plusieurs sources d’authentification (par exemple, chaque application possède son propre répertoire d’utilisateurs), migrez vers un compte unifié dans l’ID externe. Vous devrez peut-être appliquer votre propre logique métier pour fusionner et rapprocher les comptes pour le même utilisateur provenant de différentes sources.
• Les noms d’utilisateur doivent être uniques par compte dans External. Si plusieurs applications utilisent des noms d’utilisateur différents, vous devez appliquer votre propre logique métier pour rapprocher et fusionner des comptes. Pour le mot de passe, laissez l’utilisateur en choisir un et le définir dans le répertoire. Seul le mot de passe choisi doit être stocké dans le compte d’ID externe.
• Supprimez les comptes d’utilisateur inutilisés ou ne migrez pas les comptes obsolètes.

Étape 1 : Migration des données utilisateur

La première étape du processus de migration consiste à migrer les données utilisateur de votre fournisseur d’identité hérité vers l’ID externe. Cela inclut les noms d’utilisateur et tous les autres attributs pertinents. Pour ce faire, vous devez :

1. Lisez les comptes d’utilisateur de votre ancien fournisseur d’identité.
2. Créez les comptes d’utilisateur correspondants dans votre répertoire d’ID externe. Pour plus d’informations sur la création de comptes d’utilisateur par programmation, consultez Gérer les comptes d’utilisateur grand public avec Microsoft Graph.
3. Si vous avez accès aux mots de passe en texte clair des utilisateurs, vous pouvez les définir directement sur les nouveaux comptes lors de la migration des données utilisateur. Si vous n’avez pas accès aux mots de passe en texte clair, vous devez définir un mot de passe aléatoire pour l’instant qui sera mis à jour ultérieurement dans le cadre du processus de migration de mot de passe.

Toutes les informations de votre fournisseur d’identité héritée ne doivent pas être migrées vers votre répertoire d’ID externe. Les recommandations suivantes peuvent vous aider à déterminer l’ensemble approprié d’attributs utilisateur à stocker dans l’ID externe.

DO stocker dans l’ID externe :

• Nom d’utilisateur, mot de passe, adresses e-mail, numéros de téléphone, numéros d’appartenance/identificateurs.
• Marqueurs de consentement pour la politique de confidentialité et les contrats de licence de l’utilisateur final.

NE PAS stocker dans l'identifiant externe :

• Données sensibles telles que les numéros de carte de crédit, les numéros de sécurité sociale (SSN), les dossiers médicaux ou d’autres données réglementées par les organismes gouvernementaux ou de conformité du secteur.
• Préférences marketing ou de communication, comportements des utilisateurs et insights.

Étape 2 : Migration de mot de passe

Une fois que vous avez migré les données utilisateur, vous devez migrer les mots de passe utilisateur du fournisseur d’identité hérité vers l’ID externe. Il existe deux approches recommandées pour la migration des mots de passe utilisateur : la réinitialisation de mot de passe en libre-service (SSPR) et la migration transparente. Si les mots de passe utilisateur en texte clair ne sont pas accessibles, vous devez utiliser l’une de ces méthodes. Par exemple, si :

• Le mot de passe est stocké dans Azure AD B2C.
• Le mot de passe est stocké dans un format chiffré unidirectionnel, par exemple avec une fonction de hachage.
• Le mot de passe est stocké par l'ancien fournisseur d'identité de manière inaccessible pour vous. Par exemple, lorsque le fournisseur d’identité valide les informations d’identification en appelant un service web.

Réinitialisation du mot de passe en libre-service (SSPR)

À l’aide de la fonctionnalité de réinitialisation de mot de passe en libre-service (SSPR) dans l’ID externe, les clients peuvent définir manuellement leur mot de passe la première fois qu’ils se connectent au nouveau système. Cette approche est simple à implémenter et ne nécessite aucun code personnalisé. Toutefois, il oblige les utilisateurs à réinitialiser leurs mots de passe manuellement, ce qui peut être gênant pour certains utilisateurs.

Pour utiliser cette approche, vous devez d'abord configurer SSPR dans votre instance d’ID externe et définir les stratégies de réinitialisation de mot de passe. Vous devez ensuite fournir aux utilisateurs des instructions sur la réinitialisation de leurs mots de passe à l’aide de SSPR lorsqu’ils se connectent pour la première fois. Par exemple, vous pouvez envoyer un e-mail aux utilisateurs avec des instructions sur la réinitialisation de leurs mots de passe ou l’ajout d’instructions dans votre application avant que l’utilisateur accède au flux de connexion.

Migration transparente

Si vous avez un grand nombre d’utilisateurs ou si vous souhaitez offrir une expérience plus transparente, vous pouvez utiliser l’approche de migration transparente. Ce processus permet aux utilisateurs de continuer à utiliser leurs mots de passe existants lors de la migration de leurs comptes vers l’ID externe. Pour ce faire, vous devez créer une API REST personnalisée pour valider les informations d’identification entrées par les utilisateurs sur le fournisseur d’identité hérité.

Le processus de migration fluide se compose des étapes suivantes :

1. Ajoutez un attribut d’extension aux comptes d’utilisateur qui indiquent leur état de migration.
2. Lorsqu’un client se connecte, lisez le compte d’utilisateur ID externe correspondant à l’adresse e-mail entrée.
3. Si le compte d’un client est déjà marqué comme migré, poursuivez avec le processus de connexion.
4. Si le compte de l’utilisateur n’est pas marqué comme étant déjà migré, validez le mot de passe entré par rapport au fournisseur d’identité hérité.
   1. Si le fournisseur d’identité hérité détermine que le mot de passe est incorrect, retournez un message d'erreur convivial à l’utilisateur.
   2. Si le fournisseur d’identité hérité détermine que le mot de passe est correct, utilisez l’API REST pour enregistrer le mot de passe dans le compte d'identifiant externe et modifier l’attribut d’extension pour marquer le compte comme migré.

La migration transparente se produit en deux phases. Tout d’abord, les informations d’identification héritées sont collectées et stockées dans l’ID externe. Ensuite, une fois les informations d’identification mises à jour pour un nombre suffisant d’utilisateurs, les applications peuvent être migrées pour s’authentifier directement avec l’ID externe. À ce stade, les utilisateurs migrés peuvent continuer à utiliser leurs informations d’identification existantes. Tous les utilisateurs qui n’ont pas été migrés devront réinitialiser leur mot de passe lorsqu’ils se connectent pour la première fois.

La conception générale du processus de migration fluide est illustrée dans le diagramme suivant :

Extrayez les informations d'identification de l'ancien fournisseur d'identité et mettez à jour les comptes correspondants dans External ID.

Arrêtez la collecte des informations d’identification et migrez les applications pour l’authentification avec l’ID externe. Désaffectez le fournisseur d’identité ancien.

Remarque

Si vous utilisez cette approche, il est important de protéger votre API REST contre les attaques par force brute. Un attaquant peut soumettre plusieurs mots de passe dans l’espoir de deviner les informations d’identification d’un utilisateur. Pour aider à vaincre ces attaques, arrêtez de traiter les demandes à votre API REST lorsque le nombre de tentatives de connexion dépasse un certain seuil.

Contenu connexe

Si vous migrez à partir d’Azure AD B2C, l’exemple de référentiel de migration utilisateur transparent sur GitHub contient un exemple de stratégie personnalisée de migration fluide et un exemple de code d’API REST.