Gebruikers migreren naar externe Microsoft Entra-id

In deze handleiding leert u de basisprincipes van het migreren van gebruikers en referenties van uw huidige id-provider, waaronder Azure AD B2C, naar externe Microsoft Entra-id. In deze handleiding worden verschillende oplossingen beschreven die u kunt gebruiken, afhankelijk van uw huidige configuratie. Met elk van deze benaderingen moet u een toepassing of script schrijven dat gebruikmaakt van de Microsoft Graph API om gebruikersaccounts te maken in externe id.

Belangrijk

Vanaf 1 mei 2025 is Azure AD B2C niet meer beschikbaar voor nieuwe klanten. Zie Is Azure AD B2C nog steeds beschikbaar om te kopen? in onze veelgestelde vragen voor meer informatie.

Voorwaarden

Voordat u begint met het migreren van gebruikers naar externe id, hebt u het volgende nodig:

• Een externe tenant. Kies een van de volgende methoden om er een te maken:
  • Gebruik de externe id-extensie van Microsoft Entra om rechtstreeks in Visual Studio Code een externe tenant in te stellen.
  • Maak een nieuwe externe tenant in het Microsoft Entra-beheercentrum.

Voorbereiding: Adreslijst opschonen

Voordat u begint met het migratieproces van de gebruiker, moet u de tijd nemen om gegevens op te schonen in de map van uw verouderde id-provider. Hierdoor kunt u ervoor zorgen dat u alleen de gegevens migreert die u nodig hebt en het migratieproces soepeler maakt.

• Identificeer de set gebruikerskenmerken die moeten worden opgeslagen in externe id en migreer alleen wat u nodig hebt. Indien nodig kunt u aangepaste kenmerken binnen de External ID creëren om meer gegevens over een gebruiker op te slaan.
• Als u migreert vanuit een omgeving met meerdere verificatiebronnen (bijvoorbeeld elke toepassing heeft een eigen gebruikersmap), migreert u naar een uniform account in externe id. Mogelijk moet u uw eigen bedrijfslogica toepassen om accounts voor dezelfde gebruiker uit verschillende bronnen samen te voegen en af te stemmen.
• Gebruikersnamen moeten uniek zijn per account in Extern. Als meerdere toepassingen verschillende gebruikersnamen gebruiken, moet u uw eigen bedrijfslogica toepassen om accounts af te stemmen en samen te voegen. Laat de gebruiker voor het wachtwoord een wachtwoord kiezen en deze instellen in de map. Alleen het gekozen wachtwoord moet worden opgeslagen in het externe id-account.
• Verwijder ongebruikte gebruikersaccounts of migreer verouderde accounts niet.

Fase 1: Migratie van gebruikersgegevens

De eerste stap in het migratieproces is het migreren van gebruikersgegevens van uw verouderde id-provider naar externe id. Dit omvat gebruikersnamen en andere relevante kenmerken. Hiervoor doet u het volgende:

1. Lees de gebruikersaccounts van uw verouderde id-provider.
2. Maak de bijbehorende gebruikersaccounts in je directory Externe ID. Zie Gebruikersaccounts beheren met Microsoft Graph voor informatie over het programmatisch maken van gebruikersaccounts.
3. Als u toegang hebt tot de platte tekst wachtwoorden van gebruikers, kunt u deze rechtstreeks instellen op de nieuwe accounts terwijl u gebruikersdata migreert. Als u geen toegang hebt tot de wachtwoorden zonder opmaak, moet u een willekeurig wachtwoord instellen voor nu dat later wordt bijgewerkt als onderdeel van het migratieproces voor wachtwoorden.

Niet alle informatie in uw verouderde id-provider moet worden gemigreerd naar uw externe id-map. De volgende aanbevelingen kunnen u helpen bij het bepalen van de juiste set gebruikerskenmerken die moeten worden opgeslagen in externe id.

DO opslaan in Externe ID:

• Gebruikersnaam, wachtwoord, e-mailadressen, telefoonnummers, lidmaatschapsnummers/id's.
• Toestemmingsmarkeringen voor privacybeleid en gebruiksrechtovereenkomsten voor eindgebruikers.

NIET opslaan in Externe ID:

• Gevoelige gegevens zoals creditcardnummers, burgerservicenummers (SSN), medische dossiers of andere gegevens die worden gereguleerd door overheids- of branchenalevingsinstanties.
• Marketing- of communicatievoorkeuren, gebruikersgedrag en inzichten.

Fase 2: Wachtwoordmigratie

Nadat u gebruikersgegevens hebt gemigreerd, moet u gebruikerswachtwoorden migreren van de verouderde id-provider naar externe id. Er zijn twee aanbevolen methoden voor het migreren van gebruikerswachtwoorden: selfservice voor wachtwoordherstel (SSPR) en naadloze migratie. Als wachtwoorden van gebruikers zonder opmaak niet toegankelijk zijn, moet u een van deze methoden gebruiken. Bijvoorbeeld:

• Het wachtwoord wordt opgeslagen in Azure AD B2C.
• Het wachtwoord wordt opgeslagen in een eenzijdig versleutelde formaat, zoals met een hashfunctie.
• Het wachtwoord wordt opgeslagen door de verouderde id-provider op een manier die u niet kunt openen. Wanneer de id-provider bijvoorbeeld referenties valideert door een webservice aan te roepen.

Selfservice voor wachtwoordherstel (SSPR)

Met behulp van de selfservice voor wachtwoordherstel (SSPR) in externe id kunnen klanten hun wachtwoord handmatig instellen wanneer ze zich voor het eerst aanmelden bij het nieuwe systeem. Deze methode is eenvoudig te implementeren en vereist geen aangepaste code. Het vereist echter wel dat gebruikers hun wachtwoorden handmatig opnieuw instellen, wat voor sommige gebruikers onhandig kan zijn.

Als u deze methode wilt gebruiken, moet u eerst SSPR instellen in uw externe id-tenant en het beleid voor wachtwoordherstel configureren. Vervolgens moet u gebruikers instructies geven voor het opnieuw instellen van hun wachtwoorden met behulp van SSPR wanneer ze zich voor het eerst aanmelden. U kunt bijvoorbeeld een e-mailbericht verzenden naar gebruikers met instructies voor het opnieuw instellen van hun wachtwoorden of het toevoegen van instructies in uw app voordat de gebruiker naar de aanmeldingsstroom navigeert.

Naadloze migratie

Als u een groot aantal gebruikers hebt of als u een naadlozere ervaring wilt bieden, kunt u de naadloze migratiebenadering gebruiken. Met dit proces kunnen gebruikers hun bestaande wachtwoorden blijven gebruiken tijdens het migreren van hun accounts naar externe id. Hiervoor moet u een aangepaste REST API bouwen om referenties te valideren die door gebruikers zijn ingevoerd voor de verouderde id-provider.

Het naadloze migratieproces bestaat uit de volgende stappen:

1. Voeg een extensiekenmerk toe aan gebruikersaccounts die hun migratiestatus markeren.
2. Wanneer een klant zich aanmeldt, leest u het externe id-gebruikersaccount dat overeenkomt met het ingevoerde e-mailadres.
3. Als het account van een klant al is gemarkeerd als gemigreerd, gaat u verder met het aanmeldingsproces.
4. Als het account van de gebruiker niet als gemigreerd is gemarkeerd, valideert u het ingevoerde wachtwoord bij de verouderde identiteitsprovider.
   1. Als de verouderde IdP vaststelt dat het wachtwoord onjuist is, retourneert u een vriendelijke foutmelding aan de gebruiker.
   2. Als de verouderde IdP bepaalt dat het wachtwoord juist is, gebruikt u de REST API om het wachtwoord naar het externe id-account te schrijven en het extensiekenmerk te wijzigen om het account te markeren als gemigreerd.

Naadloze migratie vindt plaats in twee fasen. Ten eerste worden verouderde inloggegevens opgehaald en opgeslagen in Externe ID. Dan, zodra referenties zijn bijgewerkt voor een voldoende aantal gebruikers, kunnen toepassingen worden gemigreerd om rechtstreeks met Externe ID te authenticeren. Op dit moment kunnen gemigreerde gebruikers hun bestaande referenties blijven gebruiken. Gebruikers die niet zijn gemigreerd, moeten hun wachtwoord opnieuw instellen wanneer ze zich voor het eerst aanmelden.

Het ontwerp op hoog niveau voor het naadloze migratieproces wordt weergegeven in het volgende diagram:

Verzamel inloggegevens van de verouderde identity provider en werk de bijbehorende accounts bij in External ID.

Stop met het verzamelen van referenties en migreer toepassingen om te authenticeren met Externe ID. De verouderde id-provider buiten gebruik stellen.

Opmerking

Als u deze benadering gebruikt, is het belangrijk om uw REST API te beschermen tegen beveiligingsaanvallen. Een aanvaller kan verschillende wachtwoorden proberen in de hoop uiteindelijk de inloggegevens van een gebruiker te raden. Als u dergelijke aanvallen wilt verslaan, stopt u met het verwerken van aanvragen voor uw REST API wanneer het aantal aanmeldingspogingen een bepaalde drempelwaarde overschrijdt.

Verwante inhoud

Als u migreert vanuit Azure AD B2C, bevat de voorbeeldopslagplaats voor naadloze gebruikersmigratie op GitHub een voorbeeld van aangepast migratiebeleid en voorbeeld van REST API-code.