Вход в Microsoft Entra ID с помощью адреса электронной почты в качестве альтернативного имени для входа (предварительная версия)

Примечание.

Вход в Microsoft Entra ID с помощью электронной почты в качестве альтернативного идентификатора входа — это общедоступная предварительная версия идентификатора Microsoft Entra ID. См. подробные сведения о дополнительных условиях использования предварительных выпусков Microsoft Azure.

Многие организации хотят разрешить пользователям входить в Идентификатор Microsoft Entra, используя те же учетные данные, что и локальная среда каталога. При таком подходе, известном как гибридная проверка подлинности, пользователям нужно запоминать только один набор учетных данных.

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

  • По умолчанию имя участника-пользователя (UPN) Microsoft Entra имеет то же значение, что и локальное имя участника-пользователя.
  • Изменение имени участника-участника-участника Microsoft Entra создает несоответствие между локальными средами и средами Microsoft Entra, которые могут вызвать проблемы с определенными приложениями и службами.
  • Из-за бизнес-или соответствия требованиям организация не хочет использовать локальную имя участника-пользователя для входа в идентификатор Microsoft Entra ID.

Чтобы перейти к гибридной проверке подлинности, можно настроить идентификатор Microsoft Entra, чтобы пользователи могли войти с помощью электронной почты в качестве альтернативного идентификатора входа. Например, если Contoso сменила имя на Fabrikam, вместо того чтобы продолжать входить с помощью устаревшего имени участника-пользователя ana@contoso.com, можно использовать адрес электронной почты в качестве альтернативного имени для входа. Чтобы получить доступ к приложению или службе, пользователи войдете в идентификатор Microsoft Entra с помощью электронной почты, отличной от имени участника-пользователя, например ana@fabrikam.com.

Diagram of email as an alternate login ID.

В этой статье показано, как включить и использовать адрес электронной почты в качестве альтернативного имени для входа.

Подготовка к работе

Далее приводятся сведения об адресе электронной почты в качестве альтернативного имени для входа:

  • Эта функция доступна в бесплатном выпуске Microsoft Entra ID и более поздней версии.
  • Эта функция включает вход с помощью ProxyAddresses, а также имени участника-пользователя для пользователей Microsoft Entra, прошедших проверку подлинности в облаке. Дополнительные сведения о том, как это относится к совместной работе Microsoft Entra business-to-business (B2B) в разделе B2B .
  • Когда пользователь входит в систему с помощью адреса электронной почты, отличного от UPN, в утверждениях unique_name и preferred_username (если они есть) в маркере идентификации будет возвращен адрес электронной почты, отличный от имени субъекта-пользователя.
    • Если используемый адрес электронной почты, который не является именем участника-пользователя, становится устаревшим (больше не принадлежит пользователю), эти утверждения будут возвращать имя участника-пользователя.
  • Эта функция поддерживает управляемую проверку подлинности с помощью синхронизации хэша паролей (PHS) или сквозной проверки подлинности (PTA).
  • Существует два варианта настройки функции:
    • Политика обнаружения домашней области (HRD). Используйте этот параметр, чтобы включить функцию для всего клиента. Требуется роль глобального Администратор istrator, application Администратор istrator или Cloud Application Администратор istrator.
    • Политика поэтапного развертывания . Используйте этот параметр для проверки функции с определенными группами Microsoft Entra. Необходимые права глобального Администратор istrator. При первом добавлении группы безопасности для поэтапного развертывания вы можете ограничиться 200 пользователями, чтобы избежать истечения времени ожидания пользовательского интерфейса. После добавления группы вы можете добавить в нее дополнительных пользователей по мере необходимости.

Ограничения предварительной версии

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

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

    • Пользователю предлагается войти с помощью имени участника-пользователя при перенаправлении на вход в Microsoft Entra с помощью login_hint=<non-UPN email>.
    • Когда пользователь входит в систему с помощью адреса электронной почты, отличного от имени участника-пользователя, и вводит неправильный пароль, на странице ввода пароля изменяется UPN.
    • На некоторых веб-сайтах и в приложениях Майкрософт, например Microsoft Office, элемент управления Диспетчер учетных записей, обычно отображаемый в правом верхнем углу, может показывать пользовательское имя участника-пользователя, а не адрес электронной почты, отличный от UPN, для входа.
  • Неподдерживаемые потоки. Некоторые потоки в настоящее время несовместимы с адресами электронной почты, отличными от имени участника-пользователя, например:

    • Защита идентификации не сопоставляет адреса электронной почты, отличные от имени участника-пользователя, с обнаружением риска Утечка учетных данных. Это обнаружение рисков использует имя участника-пользователя для сопоставления учетных данных, которые подверглись утечке. Для дополнительных сведений см. Руководство. Анализ риска.
    • Когда пользователь входит с помощью адреса электронной почты, отличного от имени участника-пользователя, он не может изменить свой пароль. Самостоятельный сброс пароля Microsoft Entra (SSPR) должен работать должным образом. Во время SSPR пользователь может видеть свое имя участника-пользователя, если он подтверждает свое удостоверение через альтернативный адрес электронной почты (без использования имени участника-пользователя).
  • Неподдерживаемые сценарии. Не поддерживаются указанные ниже сценарии. Вход в систему с помощью адреса электронной почты, отличного от имени субъекта-пользователя, на:

  • Неподдерживаемые приложения. Некоторые сторонние приложения могут не работать должным образом, если предполагается, что утверждения unique_name или preferred_username являются неизменяемыми или всегда будут соответствовать определенному атрибуту пользователя, например имени субъекта-пользователя.

  • Ведение журнала. Изменения, внесенные в конфигурацию функции в политике HRD, не отображаются в журналах аудита явным образом.

  • Политика поэтапного развертывания. Следующие ограничения применяются, только если функция включена с использованием политики поэтапного развертывания:

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

Общие сведения о параметрах альтернативного имени для входа

Чтобы войти в идентификатор Microsoft Entra, пользователи введите значение, которое однозначно идентифицирует свою учетную запись. Исторически вы можете использовать только имя участника-участника-участника Microsoft Entra в качестве идентификатора входа.

Для организаций, где локальное имя участника-пользователя является предпочтительным адресом электронной почты входа пользователя, такой подход был бы отличным. Эти организации устанавливают имя участника-пользователя Microsoft Entra на то же значение, что и локальный имя участника-пользователя, и у пользователей будет согласованный вход.

Альтернативное имя для входа для AD FS

Однако в некоторых организациях локальное имя участника-пользователя не используется в качестве идентификатора входа. В локальных средах можно настроить локальную службу AD DS, чтобы разрешить вход с помощью альтернативного имени для входа. Установка имени участника-пользователя Microsoft Entra на то же значение, что и локальная имя участника-пользователя, не является параметром, так как идентификатор Microsoft Entra id затем требует, чтобы пользователи входить с этим значением.

Альтернативный идентификатор входа в Microsoft Entra Подключение

Обычное решение этой проблемы заключается в том, чтобы задать имя участника-пользователя Microsoft Entra на адрес электронной почты, с которым пользователь ожидает войти. Этот подход работает, хотя приводит к разным именам участника-пользователя между локальным ad и идентификатором Microsoft Entra, и эта конфигурация несовместима со всеми рабочими нагрузками Microsoft 365.

Адрес электронной почты в качестве альтернативного имени для входа

Другой подход заключается в синхронизации идентификатора Microsoft Entra и локальных имен участника-пользователя с тем же значением, а затем настроить идентификатор Microsoft Entra, чтобы пользователи могли войти в Microsoft Entra ID с проверенным адресом электронной почты. Чтобы предоставить эту возможность, необходимо определить один адрес электронной почты или несколько в атрибуте пользователя ProxyAddresses в локальном каталоге. Затем proxyAddresses синхронизируются с идентификатором Microsoft Entra ID автоматически с помощью Microsoft Entra Подключение.

Параметр Описание
Альтернативное имя для входа для AD FS Включение входа с помощью альтернативного атрибута (например, электронной почты) для пользователей AD FS.
Альтернативный идентификатор входа в Microsoft Entra Подключение Синхронизация альтернативного атрибута (например, Mail) в качестве имени участника-участника-участника Microsoft Entra.
Адрес электронной почты в качестве альтернативного имени для входа Включите вход с проверенным доменом ProxyAddresses для пользователей Microsoft Entra.

Синхронизация адресов электронной почты входа с идентификатором Microsoft Entra

Традиционная проверка подлинности доменных служб Active Directory Services (AD DS) или служб федерации Active Directory (AD FS) производится непосредственно в вашей сети и обрабатывается вашей инфраструктурой AD DS. При гибридной проверке подлинности пользователи могут выполнять вход непосредственно в идентификатор Microsoft Entra.

Для поддержки этого гибридного подхода проверки подлинности необходимо синхронизировать локальную среду AD DS с идентификатором Microsoft Entra с помощью Microsoft Entra Подключение и настроить ее для использования PHS или PTA. Дополнительные сведения см. в разделе "Выбор правильного метода проверки подлинности" для решения гибридного удостоверения Microsoft Entra.

В обоих параметрах конфигурации пользователь отправляет имя пользователя и пароль в идентификатор Microsoft Entra, который проверяет учетные данные и выдает билет. При входе пользователей в идентификатор Microsoft Entra удаляет необходимость размещения и управления инфраструктурой AD FS в вашей организации.

Одним из атрибутов пользователя, которые автоматически синхронизируются Microsoft Entra Подключение, является ProxyAddresses. Если у пользователей есть адрес электронной почты, определенный в локальной среде AD DS в рамках атрибута ProxyAddresses , он автоматически синхронизируется с идентификатором Microsoft Entra. Затем этот адрес электронной почты можно использовать непосредственно в процессе входа в Microsoft Entra в качестве альтернативного идентификатора входа.

Важно!

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

Дополнительные сведения см. в разделе "Добавление и проверка имени личного домена" в идентификаторе Microsoft Entra.

Вход гостевого пользователя B2B с помощью адреса электронной почты

Diagram of email as an alternate login ID for B 2 B guest user sign-in.

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

Примечание.

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

Включение входа пользователя с помощью адреса электронной почты

Примечание.

Этот параметр конфигурации использует политику HRD. Дополнительные сведения см. в статье Тип ресурса homeRealmDiscoveryPolicy.

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

Во время предварительной версии в настоящее время требуются разрешения глобального Администратор istrator, чтобы включить вход с помощью электронной почты в качестве альтернативного идентификатора входа. Для настройки функции можно использовать Центр администрирования Microsoft Entra или Graph PowerShell.

Центр администрирования Microsoft Entra

Совет

Действия, описанные в этой статье, могут немного отличаться на портале, с который вы начинаете работу.

  1. Войдите в Центр администрирования Microsoft Entra в качестве глобального Администратор istrator.

  2. В меню навигации в левой части окна Microsoft Entra выберите Microsoft Entra Подключение > Email в качестве альтернативного идентификатора входа.

    Screenshot of email as alternate login ID option in the Microsoft Entra admin center.

  3. Установите флажок рядом с Электронная почта как альтернативное имя для входа.

  4. Нажмите кнопку Сохранить.

    Screenshot of email as alternate login ID blade in the Microsoft Entra admin center.

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

PowerShell

Примечание.

Этот параметр конфигурации использует политику HRD. Дополнительные сведения см. в статье Тип ресурса homeRealmDiscoveryPolicy.

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

Чтобы выполнить следующие действия, вам потребуются права глобального Администратор istrator:

  1. Откройте сеанс PowerShell от имени администратора, а затем установите модуль Microsoft.Graph с помощью командлета Install-Module:

    Install-Module Microsoft.Graph
    

    Дополнительные сведения об установке см. в статье Установка Microsoft Graph PowerShell SDK.

  2. Войдите в клиент Microsoft Entra с помощью командлета Connect-MgGraph :

    Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration" -TenantId organizations
    

    Команда запросит пройти проверку подлинности с помощью веб-браузера.

  3. Убедитесь, что политика обнаружения домашней области HomeRealmDiscoveryPolicy (HRD) уже существует в клиенте. Для этого используйте командлет Get-MgPolicyHomeRealmDiscoveryPolicy следующим образом:

    Get-MgPolicyHomeRealmDiscoveryPolicy
    
  4. Если политика в настоящее время не настроена, команда не возвращает ничего. Если возвращается политика, пропустите этот шаг и перейдите к следующему шагу, чтобы обновить существующую политику.

    Чтобы добавить HomeRealmDiscoveryPolicy в клиент, используйте командлет New-MgPolicyHomeRealmDiscoveryPolicy и задайте для атрибута AlternateIdLogin значение "Enabled": true, как показано в следующем примере:

    $AzureADPolicyDefinition = @(
      @{
         "HomeRealmDiscoveryPolicy" = @{
            "AlternateIdLogin" = @{
               "Enabled" = $true
            }
         }
      } | ConvertTo-JSON -Compress
    )
    
    $AzureADPolicyParameters = @{
      Definition            = $AzureADPolicyDefinition
      DisplayName           = "BasicAutoAccelerationPolicy"
      AdditionalProperties  = @{ IsOrganizationDefault = $true }
    }
    
    New-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
    

    После успешного создания политики эта команда возвращает идентификатор политики, как показано в следующем примере выходных данных:

    Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
    ----------                                                           --------------- ----------- -----------                 --            ---------------------
    {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
    
  5. Если настроенная политика уже существует, проверьте, включен ли атрибут AlternateIdLogin, как показано в следующем примере выходных данных политики:

    Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
    ----------                                                           --------------- ----------- -----------                 --            ---------------------
    {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
    

    Если политика существует, но атрибут AlternateIdLogin , который не присутствует или включен, или если другие атрибуты существуют в политике, которую вы хотите сохранить, обновите существующую политику с помощью командлета Update-MgPolicyHomeRealmDiscoveryPolicy .

    Важно!

    При обновлении политики убедитесь, что в нее включены все старые параметры и новый атрибут AlternateIdLogin.

    В примере ниже добавляется атрибут AlternateIdLogin и сохраняется атрибут AllowCloudPasswordValidation, который был задан ранее.

    $AzureADPolicyDefinition = @(
      @{
         "HomeRealmDiscoveryPolicy" = @{
            "AllowCloudPasswordValidation" = $true
            "AlternateIdLogin" = @{
               "Enabled" = $true
            }
         }
      } | ConvertTo-JSON -Compress
    )
    
    $AzureADPolicyParameters = @{
      HomeRealmDiscoveryPolicyId = "HRD_POLICY_ID"
      Definition                 = $AzureADPolicyDefinition
      DisplayName                = "BasicAutoAccelerationPolicy"
      AdditionalProperties       = @{ "IsOrganizationDefault" = $true }
    }
    
    Update-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
    

    Убедитесь, что обновленная политика отображает изменения и атрибут AlternateIdLogin включен:

    Get-MgPolicyHomeRealmDiscoveryPolicy
    

Примечание.

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

Удаление политик

Чтобы удалить политику HRD, используйте командлет Remove-MgPolicyHomeRealmDiscoveryPolicy:

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

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

Примечание.

Этот параметр конфигурации использует политику поэтапного развертывания. Дополнительные сведения см. в статье тип ресурса featureRolloutPolicy.

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

Для выполнения следующих действий требуются разрешения глобального Администратор istrator:

  1. Откройте сеанс PowerShell от имени администратора, а затем установите модуль Microsoft.Graph.Beta с помощью командлета Install-Module :

    Install-Module Microsoft.Graph.Beta
    

    При появлении запроса выберите Y для установки NuGet или установки из ненадежного репозитория.

  2. Войдите в клиент Microsoft Entra с помощью командлета Подключение-MgGraph:

    Connect-MgGraph -Scopes "Directory.ReadWrite.All"
    

    Команда возвращает информацию о вашей учетной записи, среде и идентификаторе клиента.

  3. Перечисление всех существующих политик поэтапного развертывания с помощью следующего командлета:

    Get-MgBetaPolicyFeatureRolloutPolicy
    
  4. Если для этой функции нет существующих политик поэтапного развертывания, создайте новую политику промежуточного развертывания и запишите идентификатор политики:

    $MgPolicyFeatureRolloutPolicy = @{
    Feature    = "EmailAsAlternateId"
    DisplayName = "EmailAsAlternateId Rollout Policy"
    IsEnabled   = $true
    }
    New-MgBetaPolicyFeatureRolloutPolicy @MgPolicyFeatureRolloutPolicy
    
  5. Найдите идентификатор directoryObject для группы, которая будет добавлена в политику поэтапного развертывания. Запишите возвращенное значение для параметра Id, так как оно будет использоваться на следующем шаге.

    Get-MgGroup -Filter "DisplayName eq 'Name of group to be added to the staged rollout policy'"
    
  6. Добавьте группу в политику поэтапного развертывания, как показано в следующем примере. Замените значение в параметре -FeatureRolloutPolicyId значением, возвращаемым для идентификатора политики на шаге 4, и замените значение в параметре -OdataId идентификатором, указанным на шаге 5. Может потребоваться до 1 часа, прежде чем пользователи в группе могут войти в Microsoft Entra ID с помощью электронной почты в качестве альтернативного идентификатора входа.

    New-MgBetaDirectoryFeatureRolloutPolicyApplyToByRef `
       -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" `
       -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/{GROUP_OBJECT_ID}"
    

Для новых участников, добавленных в группу, может потребоваться до 24 часов, прежде чем они смогут войти в Microsoft Entra ID с помощью электронной почты в качестве альтернативного идентификатора входа.

Удаление групп

Чтобы удалить группу из политики поэтапного развертывания, выполните следующую команду:

Remove-MgBetaPolicyFeatureRolloutPolicyApplyToByRef -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -DirectoryObjectId "GROUP_OBJECT_ID"

Удаление политик

Чтобы удалить политику поэтапного развертывания, сначала отключите ее, а затем удалите из системы:

Update-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -IsEnabled:$false 
Remove-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID"

Проверка входа пользователя с помощью адреса электронной почты

Чтобы проверить возможность входа пользователей с помощью адреса электронной почты, перейдите на страницу https://myprofile.microsoft.com и войдите, используя адрес электронной почты, отличный от имени участника-пользователя, например balas@fabrikam.com. Процедура входа в систему должна выглядеть так же, как и вход с помощью UPN.

Устранение неполадок

Если у пользователей возникают проблемы со входом с помощью их адреса электронной почты, ознакомьтесь со следующими действиями по устранению неполадок:

  1. Убедитесь, что прошел по крайней мере один час после включения альтернативного имени для входа. Если пользователя недавно добавили в группу для политики поэтапного развертывания, убедитесь, что после этого прошло не менее 24 часов.

  2. Если используется политика HRD, убедитесь, что свойство Определения AlternateIdLogin имеет значение "Включено", а свойство IsOrganizationDefault имеет значение True, а свойство IsOrganizationDefault имеет значение True:

    Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
    

    Если используется политика поэтапного развертывания, убедитесь, что компонент FeatureRolloutPolicy в Microsoft Entra ID имеет свойство IsEnabled с значением True:

    Get-MgBetaPolicyFeatureRolloutPolicy
    
  3. Убедитесь, что учетная запись пользователя имеет свой адрес электронной почты в атрибуте ProxyAddresses в идентификаторе Microsoft Entra.

Журналы входа

Screenshot of Microsoft Entra sign-in logs showing email as alternate login ID activity.

Дополнительные сведения см . в журналах входа в идентификаторе Microsoft Entra. Входы с электронной почтой в качестве альтернативного идентификатора входа будут выдавать proxyAddress в поле Тип идентификатора входа и введенное имя пользователя в поле Идентификатор входа.

Конфликтующие значения между пользователями только в облаке и синхронизированными пользователями

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

  1. Откройте сеанс PowerShell от имени администратора, а затем установите модуль AzureADPreview с помощью командлета Install-Module:

    Install-Module Microsoft.Graph.Beta
    

    При появлении запроса выберите Y для установки NuGet или установки из ненадежного репозитория.

  2. Войдите в клиент Microsoft Entra в качестве глобального Администратор istrator с помощью командлета Подключение-AzureAD:

    Connect-MgGraph -Scopes "User.Read.All"
    
  3. Получить затронутых пользователей.

    # Get all users
    $allUsers = Get-MgUser -All
    
    # Get list of proxy addresses from all synced users
    $syncedProxyAddresses = $allUsers |
        Where-Object {$_.ImmutableId} |
        Select-Object -ExpandProperty ProxyAddresses |
        ForEach-Object {$_ -Replace "smtp:", ""}
    
    # Get list of user principal names from all cloud-only users
    $cloudOnlyUserPrincipalNames = $allUsers |
        Where-Object {!$_.ImmutableId} |
        Select-Object -ExpandProperty UserPrincipalName
    
    # Get intersection of two lists
    $duplicateValues = $syncedProxyAddresses |
        Where-Object {$cloudOnlyUserPrincipalNames -Contains $_}
    
  4. Для вывода затронутых пользователей:

    # Output affected synced users
    $allUsers |
        Where-Object {$_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0} |
        Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
    
    # Output affected cloud-only users
    $allUsers |
        Where-Object {!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName} |
        Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
    
  5. Для вывода затронутых пользователей в CSV-файл:

    # Output affected users to CSV
    $allUsers |
        Where-Object {
            ($_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0) -Or
            (!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName)
        } |
        Select-Object ObjectId, DisplayName, UserPrincipalName, @{n="ProxyAddresses"; e={$_.ProxyAddresses -Join ','}}, @{n="IsSyncedUser"; e={$_.ImmutableId.Length -GT 0}}, UserType |
        Export-Csv -Path .\AffectedUsers.csv -NoTypeInformation
    

Следующие шаги

Дополнительные сведения о гибридном удостоверении, например прокси приложения Microsoft Entra или доменных службах Microsoft Entra, см. в статье Microsoft Entra hybrid identity for access and management of on-prem workloads.

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