Migrera användare till Azure AD B2C

Migrering från en annan identitetsprovider till Azure Active Directory B2C (Azure AD B2C) kan också kräva migrering av befintliga användarkonton. Två migreringsmetoder beskrivs här, före migrering och sömlös migrering. Med endera metoden måste du skriva ett program eller skript som använder Microsoft Graph API för att skapa användarkonton i Azure AD B2C.

Titta på den här videon om du vill veta mer om Azure AD migreringsstrategier för B2C-användare och steg att överväga.

Anteckning

Innan du påbörjar migreringen kontrollerar du att din Azure AD B2C-klientorganisations oanvända kvot kan hantera alla användare som du förväntar dig att migrera. Lär dig hur du hämtar din klientanvändning. Om du behöver öka klientorganisationens kvotgräns kontaktar du Microsoft Support.

Före migrering

I flödet före migreringen utför migreringsprogrammet följande steg för varje användarkonto:

1. Läs användarkontot från den gamla identitetsprovidern, inklusive dess aktuella autentiseringsuppgifter (användarnamn och lösenord).
2. Skapa ett motsvarande konto i din Azure AD B2C-katalog med aktuella autentiseringsuppgifter.

Använd flödet före migreringen i någon av följande två situationer:

• Du har åtkomst till en användares autentiseringsuppgifter i klartext (användarnamn och lösenord).
• Autentiseringsuppgifterna är krypterade, men du kan dekryptera dem.

Information om hur du programmatiskt skapar användarkonton finns i Hantera Azure AD B2C-användarkonton med Microsoft Graph.

Sömlös migrering

Använd det sömlösa migreringsflödet om lösenord i klartext i den gamla identitetsprovidern inte är tillgängliga. Här är några exempel:

• Lösenordet lagras i ett enkelriktat krypterat format, till exempel med en hash-funktion.
• Lösenordet lagras av den äldre identitetsprovidern på ett sätt som du inte kan komma åt. Till exempel när identitetsprovidern verifierar autentiseringsuppgifter genom att anropa en webbtjänst.

Det sömlösa migreringsflödet kräver fortfarande före migrering av användarkonton, men använder sedan en anpassad princip för att fråga ett REST-API (som du skapar) för att ange varje användares lösenord vid första inloggningen.

Det sömlösa migreringsflödet består av två faser: före migreringen och ange autentiseringsuppgifter.

Fas 1: Före migrering

1. Migreringsprogrammet läser användarkontona från den gamla identitetsprovidern.
2. Migreringsprogrammet skapar motsvarande användarkonton i din Azure AD B2C-katalog, men anger slumpmässiga lösenord som du genererar.

Fas 2: Ange autentiseringsuppgifter

När förmigreringen av kontona är klar utför din anpassade princip och REST API följande när en användare loggar in:

1. Läs det Azure AD B2C-användarkonto som motsvarar den angivna e-postadressen.
2. Kontrollera om kontot har flaggats för migrering genom att utvärdera ett booleskt tilläggsattribut.
   • Om tilläggsattributet returnerar anropar Truedu rest-API:et för att verifiera lösenordet mot den äldre identitetsprovidern.
     • Om REST-API:et fastställer att lösenordet är felaktigt returnerar du ett användarvänligt fel till användaren.
     • Om REST-API:et fastställer att lösenordet är korrekt skriver du lösenordet till Azure AD B2C-kontot och ändrar det booleska tilläggsattributet till False.
   • Om det booleska tilläggsattributet returnerar Falsefortsätter du inloggningsprocessen som vanligt.

Ett exempel på en anpassad princip och ETT REST-API finns i exemplet på sömlös användarmigrering på GitHub.

Säkerhet

Den sömlösa migreringsmetoden använder ditt eget anpassade REST-API för att verifiera en användares autentiseringsuppgifter mot den äldre identitetsprovidern.

Du måste skydda rest-API:et mot råstyrkeattacker. En angripare kan skicka flera lösenord i hopp om att så småningom gissa en användares autentiseringsuppgifter. För att förhindra sådana attacker kan du sluta skicka begäranden till rest-API:et när antalet inloggningsförsök överskrider ett visst tröskelvärde. Skydda även kommunikationen mellan Azure AD B2C och ditt REST-API. Information om hur du skyddar dina RESTful-API:er för produktion finns i Skydda RESTful API.

Användarattribut

All information i den äldre identitetsprovidern bör inte migreras till din Azure AD B2C-katalog. Identifiera lämplig uppsättning användarattribut som ska lagras i Azure AD B2C innan du migrerar.

• DO store i Azure AD B2C:
  • Användarnamn, lösenord, e-postadresser, telefonnummer, medlemsnummer/identifierare.
  • Medgivandemarkörer för sekretesspolicy och slutanvändarlicensavtal.
• Lagra inte i Azure AD B2C:
  • Känsliga data som kreditkortsnummer, personnummer (SSN), medicinska journaler eller andra data som regleras av myndigheter eller branschefterlevnadsorgan.
  • Marknadsförings- eller kommunikationsinställningar, användarbeteenden och insikter.

Katalogrensning

Innan du påbörjar migreringsprocessen bör du ta tillfället i akt att rensa katalogen.

• Identifiera uppsättningen användarattribut som ska lagras i Azure AD B2C och migrera bara det du behöver. Om det behövs kan du skapa anpassade attribut för att lagra mer data om en användare.
• Om du migrerar från en miljö med flera autentiseringskällor (till exempel om varje program har en egen användarkatalog) migrerar du till ett enhetligt konto i Azure AD B2C.
• Om flera program har olika användarnamn kan du lagra alla i ett Azure AD B2C-användarkonto med hjälp av identitetssamlingen. Om lösenordet låter du användaren välja ett och ange det i katalogen. Med den sömlösa migreringen ska till exempel endast det valda lösenordet lagras i Azure AD B2C-kontot.
• Ta bort oanvända användarkonton eller migrera inte inaktuella konton.

Lösenordsprincip

Om de konton som du migrerar har svagare lösenordsstyrka än den starka lösenordsstyrka som framtvingas av Azure AD B2C kan du inaktivera kravet på starka lösenord. Mer information finns i Egenskapen Lösenordsprincip.

Nästa steg

Lagringsplatsen azure-ad-b2c/user-migration på GitHub innehåller ett exempel på sömlös migrering av anpassad princip och KODexempel för REST API:

Sömlös anpassad princip för användarmigrering och KODexempel för REST API