Поделиться через


Вход в 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.

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

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

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

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

  • Эта функция доступна в бесплатном выпуске Microsoft Entra ID и более поздней версии.

  • Эта функция включает вход с помощью ProxyAddresses, а также имени участника-пользователя для пользователей Microsoft Entra, прошедших проверку подлинности в облаке. Дополнительные сведения о том, как это относится к совместной работе Microsoft Entra business-to-business (B2B) в разделе B2B .

  • Когда пользователь входит в систему с помощью адреса электронной почты, отличного от UPN, в утверждениях unique_name и preferred_username (если они есть) в маркере идентификации будет возвращен адрес электронной почты, отличный от имени субъекта-пользователя.

    • Если используемый адрес электронной почты, который не является именем участника-пользователя, становится устаревшим (больше не принадлежит пользователю), эти утверждения будут возвращать имя участника-пользователя.
  • Эта функция поддерживает управляемую проверку подлинности с помощью синхронизации хэша паролей (PHS) или сквозной проверки подлинности (PTA).

  • Настройку функции можно выполнить двумя способами:

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

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

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

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

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

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

    • Защита идентификации Microsoft Entra не соответствует сообщениям электронной почты без имени участника-участника с Обнаружение рисков утечки учетных данных. Это обнаружение рисков использует имя участника-пользователя для сопоставления учетных данных, которые подверглись утечке. Для дополнительных сведений см. Руководство. Анализ риска.
    • Когда пользователь входит с помощью адреса электронной почты, отличного от имени участника-пользователя, он не может изменить свой пароль. Самостоятельный сброс пароля 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 Connect

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

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

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

Вариант Описание
Альтернативное имя для входа для AD FS Включение входа с помощью альтернативного атрибута (например, электронной почты) для пользователей AD FS.
Альтернативный идентификатор входа в Microsoft Entra Connect Синхронизация альтернативного атрибута (например, 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 Id с помощью Microsoft Entra Connect и настроить ее для использования PHS или PTA. Дополнительные сведения см. в разделе "Выбор правильного метода проверки подлинности" для решения гибридного удостоверения Microsoft Entra.

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

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

Внимание

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

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

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

Электронная почта как альтернативное имя для входа гостевого пользователя B2B.

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

Примечание.

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

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

Примечание.

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

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

Для настройки функции можно использовать Центр администрирования Microsoft Entra или Graph PowerShell.

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

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

Совет

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

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

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

    Снимок экрана: сообщение электронной почты в качестве альтернативного идентификатора входа в Центре администрирования Microsoft Entra.

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

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

    Снимок экрана: колонка

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

PowerShell

Примечание.

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

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

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

  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.

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

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

    Install-Module Microsoft.Graph.Beta
    

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

  2. Войдите в клиент Microsoft Entra с помощью командлета Connect-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-MgBetaGroup -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.

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

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

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

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

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

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

    Install-Module Microsoft.Graph.Beta
    

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

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

    Войдите в клиент Microsoft Entra с помощью командлета Connect-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.

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