Миграция пользователей в Azure AD B2C

Миграция с другого поставщика удостоверений на Azure Active Directory B2C (Azure AD B2C) также может потребовать миграции существующих учетных записей пользователей. Здесь обсуждаются два метода переноса: предварительная миграция и полная миграция. При выборе любой из этих методик необходимо написать приложение или сценарий, который использует API Microsoft Graph для создания учетных записей пользователей в Azure AD B2C.

Просмотрите это видео, чтобы узнать о cтратегиях миграции пользователей Azure AD B2C и действиях, которые следует учитывать.

Примечание

Перед началом миграции убедитесь, что неиспользуемая квота клиента B2C Azure AD может вместить всех пользователей, которых вы планируете перенести. Узнайте, как получить сведения об использовании клиента. Если вам нужно увеличить квоту клиента, обратитесь к служба поддержки Майкрософт.

Предварительная миграция

В процессе предварительной миграции приложение миграции выполняет следующие действия для каждой учетной записи пользователя:

1. Чтение учетной записи пользователя из старого поставщика удостоверений, в том числе текущие учетные данные (имя пользователя и пароль).
2. Создание соответствующей учетной записи в каталоге Azure AD B2C с текущими учетными данными.

Используйте процесс предварительной миграции в любой из этих двух ситуаций:

• у вас есть доступ к учетным данным пользователя в виде открытого текста (имя пользователя и пароль).
• учетные данные шифруются, но их можно расшифровать.

Сведения о создании учетных записей пользователей программным путем см. в разделе Управление Azure AD B2C учетными записями пользователей с помощью Microsoft Graph.

Полная миграция

Используйте процесс полной миграции, если незашифрованные пароли в старом поставщике удостоверений недоступны. Например, такая необходимость может возникнуть в следующих случаях:

• пароль хранится в односторонне зашифрованном формате, например в хэш-функции;
• пароль хранится в устаревшем поставщике удостоверений в недоступном виде. Например, когда поставщик удостоверений проверяет учетные данные путем вызова веб-службы.

Для процесса полной миграции по-прежнему требуется предварительная миграция учетных записей пользователей, но затем используется настраиваемая политика для запроса REST API (созданного вами), чтобы задавать пользовательский пароль при первом входе в систему.

Таким образом, процесс полной миграции разделен на два этапа: предварительная миграция и настройка учетных данных.

Этап 1. Предварительная миграция

1. Приложение для миграции считывает учетные записи пользователей из старого поставщика удостоверений.
2. Приложение для миграции создает соответствующие учетные записи пользователей в каталоге Azure AD B2C, но устанавливает случайные пароли, сгенерированные вами.

Этап 2. Настройка учетных данных

После выполнения предварительной миграции учетных записей пользовательская политика и REST API при входе пользователя выполняют следующие действия.

1. Считывают учетную запись пользователя Azure AD B2C, соответствующую заданному адресу электронной почты.
2. Путем оценки логического атрибута расширения проверяют, помечена ли учетная запись для миграции.
   • Если атрибут расширения возвращает True, вызывают REST API, чтобы проверить пароль из устаревшего поставщика удостоверений.
     • Если REST API определяет, что пароль неправильный, возвращают пользователю информативное сообщение об ошибке.
     • Если REST API определяет, что пароль правильней, записывают пароль в учетную запись Azure AD B2C и изменяют логический атрибут расширения на False.
   • Если атрибут логического расширения возвращает False, процесс входа продолжается как обычно.

Пример пользовательской политики и REST API см. в примере полной миграции пользователей на сайте GitHub.

Безопасность

Метод полной миграции использует собственный пользовательский REST API для проверки учетных данных пользователя у устаревшего поставщика удостоверений.

Вы должны защитить свой REST API от атак методом подбора. Злоумышленник может отправить несколько паролей в конечном итоге угадать учетные данные пользователя. Чтобы избежать таких атак, прекращайте обслуживать запросы к REST API, когда число попыток входа превысит некое пороговое значение. Кроме того, обеспечьте безопасность обмена данными между Azure AD B2C и REST API. Сведения о защите RESTful API для рабочей среды см. в этой статье.

Атрибуты пользователя

Не все сведения из устаревшего поставщика удостоверений должны быть перенесены в каталог Azure AD B2C. Соответствующий набор атрибутов пользователя для хранения в Azure AD B2C укажите до начала миграции.

• Хранить в Azure AD B2C:
  • Имя пользователя, пароль, адреса электронной почты, номера телефонов, номера или идентификаторы участника.
  • Маркеры согласия для политики конфиденциальности и лицензионных соглашений для конечных пользователей.
• Не храните в Azure AD B2C:
  • Конфиденциальные данные, такие как номера кредитных карт, номера социального страхования, медицинские записи или другие данные, подлежащие правительственной регуляции или отраслевыми регуляторным органам.
  • Настройки рекламы и сообщений, данные поведения пользователей и аналитики.

Очистка каталога

Прежде чем начать процесс миграции, воспользуйтесь возможностью очистки каталога.

• Укажите набор пользовательских атрибутов, которые будут храниться в Azure AD B2C, и перенесите только необходимые данные. При необходимости можно создать настраиваемые атрибуты для хранения дополнительных данных о пользователе.
• Если выполняется миграция из среды с несколькими источниками проверки подлинности (например, каждое приложение имеет свой собственный каталог пользователя), выполните миграцию на единую учетную запись в Azure AD B2C.
• Если несколько приложений имеют разные имена пользователей, их можно хранить в учетной записи пользователя Azure AD B2C, используя коллекцию удостоверений. Предоставьте пользователю возможность выбрать пароль и назначить его в каталоге. Например, при полной миграции в учетной записи Azure AD B2C должен храниться только выбранный пароль.
• Удалите неиспользуемые учетные записи пользователей или не переносите устаревшие учетные записи.

Политика паролей

Если у переносимых учетных записей надежность пароля слабее, чем высокая надежность, обеспечиваемая Azure AD B2C, можно отключить требование надежного пароля. Дополнительные сведения см. в разделе Своство политики паролей.

Дальнейшие действия

Репозиторий azure-ad-b2c/user-migration на GitHub содержит пример удобной пользовательской политики миграции и пример кода REST API:

Пример пользовательской политики простой миграции пользователей и кода REST API