Migracja użytkowników do Microsoft Entra External ID

W tym przewodniku przedstawiono podstawy migracji użytkowników i poświadczeń z bieżącego dostawcy tożsamości, w tym usługi Azure AD B2C, do zewnętrznego identyfikatora firmy Microsoft. W tym przewodniku opisano różne rozwiązania, których można użyć w zależności od bieżącej konfiguracji. W przypadku każdego z tych podejść należy napisać aplikację lub skrypt, który używa interfejsu API programu Microsoft Graph do tworzenia kont użytkowników w identyfikatorze zewnętrznym.

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Aby dowiedzieć się więcej, zobacz Czy usługa Azure AD B2C jest nadal dostępna do zakupu? w naszych często zadawanych pytaniach.

Wymagania wstępne

Przed rozpoczęciem migracji użytkowników do identyfikatora zewnętrznego potrzebne są następujące elementy:

• Zewnętrzny najemca Aby go utworzyć, wybierz jedną z następujących metod:
  • Użyj rozszerzenia Microsoft Entra External ID , aby skonfigurować dzierżawcę zewnętrznego bezpośrednio w programie Visual Studio Code.
  • Utwórz nowego najemcę zewnętrznego w centrum administracyjnym Microsoft Entra.

Przygotowanie: Czyszczenie katalogu

Przed rozpoczęciem procesu migracji użytkowników należy poświęcić czas na wyczyszczenie danych w katalogu używanego wcześniej dostawcy tożsamości. Dzięki temu można zagwarantować, że migrujesz tylko potrzebne dane i sprawia, że proces migracji jest sprawniejszy.

• Zidentyfikuj zestaw atrybutów użytkownika do przechowywania w identyfikatorze zewnętrznym i zmigruj tylko potrzebne elementy. W razie potrzeby możesz utworzyć atrybuty niestandardowe w identyfikatorze zewnętrznym, aby przechowywać więcej danych o użytkowniku.
• Jeśli przeprowadzasz migrację ze środowiska z wieloma źródłami uwierzytelniania (na przykład każda aplikacja ma własny katalog użytkowników), przeprowadź migrację do ujednoliconego konta w identyfikatorze zewnętrznym. Może być konieczne zastosowanie własnej logiki biznesowej w celu scalenia i uzgodnienia kont dla tego samego użytkownika z różnych źródeł.
• Nazwy użytkowników muszą być unikatowe dla każdego konta w obszarze Zewnętrzne. Jeśli wiele aplikacji używa różnych nazw użytkowników, musisz zastosować własną logikę biznesową, aby uzgodnić i scalić konta. W przypadku hasła pozwól użytkownikowi wybrać jedno i ustawić je w katalogu. Tylko wybrane hasło powinno być przechowywane na koncie identyfikatora zewnętrznego.
• Usuń nieużywane konta użytkowników lub nie migruj nieaktywnych kont.

Etap 1. Migracja danych użytkowników

Pierwszym krokiem procesu migracji jest migrowanie danych użytkownika ze starszego dostawcy tożsamości do identyfikatora zewnętrznego. Obejmuje to nazwy użytkowników i inne odpowiednie atrybuty. W tym celu należy:

1. Odczytywanie kont użytkowników ze starszego dostawcy tożsamości.
2. Utwórz odpowiednie konta użytkowników w katalogu identyfikatorów zewnętrznych. Aby uzyskać informacje o programowym tworzeniu kont użytkowników, zobacz Zarządzanie kontami użytkowników konsumentów za pomocą programu Microsoft Graph.
3. Jeśli masz dostęp do haseł zwykłych użytkowników, możesz ustawić je bezpośrednio na nowych kontach podczas migrowania danych użytkowników. Jeśli nie masz dostępu do haseł w postaci zwykłego tekstu, na razie należy ustawić losowe hasło, które zostanie zaktualizowane później w ramach procesu migracji haseł.

Nie wszystkie informacje w dotychczasowym dostawcy tożsamości muszą zostać zmigrowane do zewnętrznego katalogu tożsamości. Poniższe zalecenia mogą pomóc w określeniu odpowiedniego zestawu atrybutów użytkownika do przechowywania w identyfikatorze zewnętrznym.

Przechowuj DO w identyfikatorze zewnętrznym:

• Nazwa użytkownika, hasło, adresy e-mail, numery telefonów, numery członkostwa/identyfikatory.
• Znaczniki zgody dla zasad ochrony prywatności i umów licencyjnych użytkownika końcowego.

NIE PRZECHOWUJ w identyfikatorze zewnętrznym:

• Poufne dane, takie jak numery kart kredytowych, numery ubezpieczenia społecznego (SSN), dokumentacji medycznej lub inne dane regulowane przez instytucje rządowe lub branżowe.
• Preferencje dotyczące marketingu lub komunikacji, zachowania użytkowników i szczegółowe informacje.

Etap 2. Migracja haseł

Po przeprowadzeniu migracji danych użytkownika należy przeprowadzić migrację haseł użytkowników ze starszego dostawcy tożsamości do identyfikatora zewnętrznego. Istnieją dwie zalecane metody migracji haseł użytkowników: samoobsługowe resetowanie hasła (SSPR) i bezproblemowa migracja. Jeśli hasła użytkownika w postaci zwykłego tekstu nie są dostępne, należy użyć jednej z tych metod. Na przykład jeśli:

• Hasło jest przechowywane w usłudze Azure AD B2C.
• Hasło jest przechowywane w jednokierunkowym formacie zaszyfrowanym, takim jak funkcja skrótu.
• Hasło jest przechowywane przez starszego dostawcę tożsamości w sposób, do którego nie można uzyskać dostępu. Na przykład gdy dostawca tożsamości weryfikuje poświadczenia, wywołując usługę internetową.

Samoobsługowe resetowanie hasła (SSPR)

Korzystając z funkcji samoobsługowego resetowania hasła (SSPR) w identyfikatorze zewnętrznym, klienci mogą ręcznie ustawić swoje hasło przy pierwszym logowaniu się do nowego systemu. Takie podejście jest proste do zaimplementowania i nie wymaga żadnego kodu niestandardowego. Jednak wymaga ręcznego zresetowania haseł przez użytkowników, co może być niewygodne dla niektórych użytkowników.

Aby użyć tego podejścia, najpierw należy skonfigurować funkcję samoobsługowego resetowania hasła w dzierżawie identyfikatora zewnętrznego oraz ustawić zasady resetowania haseł. Następnie powinno się dostarczyć użytkownikom instrukcji dotyczących resetowania ich haseł za pomocą SSPR przy ich pierwszym logowaniu się. Na przykład możesz wysłać wiadomość e-mail do użytkowników z instrukcjami dotyczącymi resetowania haseł lub dodawania instrukcji w aplikacji, zanim użytkownik przejdzie do przepływu logowania.

Bezproblemowa migracja

Jeśli masz dużą liczbę użytkowników lub chcesz zapewnić bardziej bezproblemowe środowisko, możesz użyć bezproblemowego podejścia do migracji. Ten proces umożliwia użytkownikom kontynuowanie korzystania z istniejących haseł podczas migrowania kont do identyfikatora zewnętrznego. W tym celu należy utworzyć niestandardowy interfejs API REST, aby zweryfikować poświadczenia wprowadzone przez użytkowników względem starszego dostawcy tożsamości.

Bezproblemowy proces migracji składa się z następujących kroków:

1. Dodaj atrybut rozszerzający do kont użytkowników, który wskazuje stan ich migracji.
2. Po zalogowaniu się klienta przeczytaj konto użytkownika identyfikatora zewnętrznego odpowiadające wprowadzonemu adresowi e-mail.
3. Jeśli konto klienta jest już oflagowane jako zmigrowane, kontynuuj proces logowania.
4. Jeśli konto użytkownika nie jest oznaczone jako już zmigrowane, zweryfikuj hasło wprowadzone dla starszego dostawcy tożsamości.
   1. Jeśli starszy dostawca tożsamości ustali, że hasło jest nieprawidłowe, zwróć przyjazny komunikat o błędzie do użytkownika.
   2. Jeśli dziedziczny IdP zidentyfikuje, że hasło jest poprawne, użyj interfejsu API REST, aby zapisać hasło w koncie External ID i zmienić atrybut rozszerzeń, aby oznaczyć konto jako zmigrowane.

Bezproblemowa migracja odbywa się w dwóch fazach. Najpierw starsze poświadczenia są zbierane i przechowywane w identyfikatorze zewnętrznym. Następnie po zaktualizowaniu poświadczeń dla wystarczającej liczby użytkowników aplikacje można migrować do uwierzytelniania bezpośrednio przy użyciu identyfikatora zewnętrznego. W tym momencie zmigrowane użytkownicy mogą nadal używać swoich istniejących poświadczeń. Każdy użytkownik, który nie został zmigrowany, będzie musiał zresetować swoje hasło podczas pierwszego logowania.

Ogólny projekt bezproblemowego procesu migracji przedstawiono na poniższym diagramie:

Pozyskaj poświadczenia ze starszego dostawcy tożsamości i zaktualizuj odpowiednie konta w External ID.

Zatrzymaj zbieranie poświadczeń i przesuń aplikacje, aby uwierzytelniały się za pomocą External ID. Zlikwidować starszego dostawcę tożsamości.

Uwaga / Notatka

Jeśli używasz tego podejścia, ważne jest, aby chronić interfejs API REST przed atakami siłowymi. Osoba atakująca może przesłać kilka haseł w nadziei na odgadnięcie poświadczeń użytkownika. Aby pomóc w pokonaniu takich ataków, zatrzymaj obsługę żądań do interfejsu API REST, gdy liczba prób logowania przekroczy określony próg.

Treści powiązane

• Jeśli przeprowadzasz migrację z usługi Azure AD B2C, bezproblemowe repozytorium przykładu migracji użytkowników w usłudze GitHub zawiera przykładowe niestandardowe zasady migracji i przykład kodu interfejsu API REST.
• Dowiedz się więcej o niestandardowych rozszerzeniach uwierzytelniania.