Миграция пользователей и учетных данных на Microsoft Entra External ID

Применяется: Внешние клиенты (дополнительные сведения)

В этом руководстве вы узнаете, как перенести пользователей и учетные данные из текущего поставщика удостоверений в Microsoft Entra External ID. Это руководство относится к любому устаревшому поставщику удостоверений (включая Azure AD B2C) и охватывает подготовку каталогов, массовую миграцию пользователей, настройку миграции учетных данных и доступные подходы к миграции учетных данных.

Необходимые условия

Прежде чем приступить к миграции пользователей на внешний идентификатор, вам потребуется:

• Внешний арендатор. Чтобы создать его, выберите один из следующих методов:
  • Используйте расширение Microsoft Entra External ID для настройки внешнего клиента непосредственно в Visual Studio Code.
  • Создайте нового внешнего арендатора в центре администрирования Microsoft Entra.

Подготовка: очистка каталога

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

• Определите набор атрибутов пользователя, хранящихся во внешнем идентификаторе, и переносите только необходимые атрибуты. При необходимости можно создать настраиваемые атрибуты в внешнем идентификаторе для хранения дополнительных данных о пользователе.
• При миграции из среды с несколькими источниками проверки подлинности (например, у каждого приложения есть собственный каталог пользователя), перейдите на единую учетную запись в External ID. Может потребоваться применить собственную бизнес-логику для слияния и согласования учетных записей для одного пользователя из разных источников.
• Имена пользователей должны быть уникальными для каждой учетной записи в системе External. Если несколько приложений используют разные имена пользователей, необходимо применить собственную бизнес-логику для согласования и слияния учетных записей. Для пароля позвольте пользователю выбрать его и задать его в каталоге. В учетной записи внешнего идентификатора должен храниться только выбранный пароль.
• Удалите неиспользуемые учетные записи пользователей или не переносите устаревшие учетные записи.

Этап 1. Перенос данных пользователя

Первым шагом в процессе миграции является перенос данных пользователей из устаревшего поставщика удостоверений в внешний идентификатор. Это включает имена пользователей и любые другие соответствующие атрибуты. Для этого необходимо выполнить следующие действия.

1. Прочитайте учетные записи пользователей из вашего устаревшего поставщика идентификации.
2. Создайте соответствующие учетные записи пользователей в каталоге внешнего идентификатора. Сведения о программном создании учетных записей пользователей см. в статье Управление потребительскими учетными записями пользователей с помощью Microsoft Graph.
3. Если у вас есть доступ к открытым паролям пользователей, их можно задать непосредственно в новых учетных записях при переносе данных пользователей. Если у вас нет доступа к паролям обычного текста, необходимо задать случайный пароль, который будет обновлен позже в процессе миграции паролей.

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

СОХРАНЯЙ во внешнем идентификаторе:

• Имя пользователя, пароль, адреса электронной почты, номера телефонов, номера участников и идентификаторы.
• Маркеры согласия для политики конфиденциальности и соглашений о лицензировании конечных пользователей.

НЕ хранить в внешнем идентификаторе:

• Конфиденциальные данные, такие как номера кредитной карты, номера социального страхования (SSN), медицинские записи или другие данные, регулируемые государственными или отраслевыми органами соответствия.
• Маркетинговые или коммуникационные предпочтения, поведение пользователей и аналитические сведения.

Альтернативные варианты миграции учетных данных

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

Если вам не нужна миграция учетных данных, миграция пользователей завершена. Обратите внимание на руководство по миграции, чтобы проверить экосистему и планировать переключение приложения: Этап 4. Проверка, мониторинг и планирование переключения.

Этап 2. Подготовка к миграции учетных данных

Если необходимо сохранить существующие пароли, подготовьте учетные записи пользователей к миграции учетных данных перед реализацией любого подхода к миграции. Эта настройка используется как для JIT, так и для устаревших подходов, инициированных IdP, описанных на этапе 3.

Определение свойства расширения для отслеживания состояния миграции

Определите свойство расширения каталога для отслеживания того, были ли перенесены учетные данные каждого пользователя из устаревшего поставщика удостоверений. Microsoft Graph поддерживает добавление настраиваемых свойств в объекты каталога через расширения directory (Microsoft Entra ID.

POST https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444/extensionProperties 

{ 
    "name": "toBeMigrated", 
    "dataType": "Boolean",
    "targetObjects":[ 
        "User" 
    ] 
} 

Получение идентификатора свойства расширения

После создания свойства расширения необходимо получить уникальный идентификатор для использования в реализации миграции учетных данных. Идентификатор свойства расширения следует этому соглашению об именовании: extension_{applicationId-without-hyphens}_{propertyName}

Чтобы создать идентификатор свойства расширения:

1. Перейдите к Entra ID>Регистрации приложений в центре администрирования Microsoft Entra.
2. Выберите все приложения из списка над списком приложений.
3. Найдите имя b2c-extensions-app приложения и скопируйте его значение идентификатора приложения (клиента ).
4. Удалите дефисы из идентификатора приложения и объедините его с именем атрибута.

Например, если идентификатор вашего приложения — это 00001111-aaaa-2222-bbbb-3333cccc4444, а имя атрибута — toBeMigrated, то идентификатор свойства расширения будет extension_00001111aaaa2222bbbb3333cccc4444_toBeMigrated.

Создание случайных надежных паролей

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

Создание пользователей с флагом миграции

Создайте учетные записи пользователей в клиенте внешнего идентификатора. Вы можете создавать пользователей с помощью Microsoft Entra admin center или программно с помощью Microsoft Graph API. Подробные инструкции по созданию пользователей см. в статье "Создание, приглашение и удаление пользователей".

В следующем примере показано, как создать пользователя с назначением миграционных свойств true с помощью Microsoft Graph API. Замените {extension-property-id} фактическим идентификатором свойства расширения, созданным на предыдущем шаге.

POST https://graph.microsoft.com/v1.0/users

{
    "creationType": "LocalAccount",
    "accountEnabled": true,
    "passwordProfile": {
        "forceChangePasswordNextSignIn": false,
        "password": "<unique-generated-random-strong-password>"
    },
    "{extension-property-id}": true
}

Пример кода для поддержки миграции пользователей можно найти в средстве миграции B2C в MEEID.

Этап 3. Перенос учетных данных

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

Миграция паролей JIT (инициированная внешним идентификатором)

При JIT-миграции приложения уже перемещены в конечные точки внешних идентификаторов. При входе пользователя внешний идентификатор использует OnPasswordSubmit пользовательское расширение проверки подлинности для проверки учетных данных пользователя в отношении устаревшего поставщика удостоверений, записывает пароль в учетную запись внешнего идентификатора и помечает учетную запись как перенесенную. Последующие входы проходят проверку подлинности непосредственно по внешнему идентификатору.

Полные инструкции по реализации см. в разделе «Just-in-time миграция паролей».

Сбор учетных данных, инициированных устаревшим поставщиком удостоверений

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

Этот подход применяется, если пароли с открытым текстом недоступны. Например, если:

• Пароль хранится наследственным поставщиком удостоверений в хэшированном или зашифрованном формате.
• Пароль управляется устаревшим поставщиком удостоверений и может быть проверен только через собственную службу проверки подлинности.

Процесс миграции учетных данных состоит из следующих шагов:

1. При входе клиента считывается пользовательская учетная запись с внешним идентификатором, соответствующая введенному адресу электронной почты.
2. Если учетная запись уже помечена как перенесенная, перейдите к обычному входу.
3. Если учетная запись не отмечена как перенесённая, проверьте пароль для устаревшего поставщика идентификаций.
   1. Если устаревший идентификатор поставщика удостоверений определяет неверный пароль, верните пользователю понятное сообщение об ошибке.
   2. Если поставщик удостоверений (IdP) определяет, что пароль правильный, запишите пароль в учетную запись внешней идентификации и обновите флаг миграции.

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

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

Сбор учетных данных от устаревшего поставщика удостоверений и обновление соответствующих учетных записей во внешнем идентификаторе.

Прекратите сбор учетных данных и перейдите на аутентификацию приложений с использованием внешнего идентификатора. Вывести из эксплуатации устаревшего поставщика удостоверений.

Завершение проверки и переключение на новую систему

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

Связанный контент

• Переход на внешний идентификатор — обзор миграции из любого устаревшего решения CIAM.
• Планируйте миграцию с Azure AD B2C на внешний идентификатор — рекомендации по принятию решений b2C и параметры сохранения паролей.
• JIT-миграция паролей — сохранение паролей во время миграции с помощью пользовательских расширений проверки подлинности.
• Службы и партнеры по интеграции для внешнего идентификатора — найдите партнера для планирования и выполнения миграции.
• Пользовательские расширения проверки подлинности — вызов внешней логики во время потоков проверки подлинности.