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

Многие организации хотят разрешить пользователям входить в Идентификатор 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 .

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

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

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

• Существует два варианта настройки функции:

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

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

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

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

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

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

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

  • Защита идентификации Microsoft Entra не соответствует сообщениям электронной почты без имени участника-участника с Обнаружение рисков утечки учетных данных. Это обнаружение рисков использует имя участника-пользователя для сопоставления учетных данных, которые были утечки. Дополнительные сведения см. в разделе "Практическое руководство . Изучение риска".
  • При входе пользователя с помощью электронной почты, отличной от имени участника-пользователя, он не может изменить пароль. Самостоятельный сброс пароля Microsoft Entra (SSPR) должен работать должным образом. Во время SSPR пользователь может увидеть имя участника-пользователя, если они проверяют свое удостоверение с помощью электронной почты, отличной от имени участника-пользователя.

• Неподдерживаемые сценарии . Следующие сценарии не поддерживаются. Войдите с помощью электронной почты, отличной от имени участника-участника:

  • Гибридные устройства, присоединенные к Microsoft Entra
  • Устройства, присоединенные к Microsoft Entra
  • Зарегистрированные устройства Microsoft Entra
  • Учетные данные владельца ресурса (ROPC)
  • Политики единого входа и защиты приложений на мобильной платформе
  • Устаревшая проверка подлинности, например POP3 и SMTP
  • Skype для бизнеса

• Неподдерживаемые приложения. Некоторые сторонние приложения могут работать неправильно, если предполагается, что 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.

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

Традиционная проверка подлинности домен Active Directory служб (AD DS) или службы федерации Active Directory (AD FS) (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 в качестве альтернативного идентификатора входа.

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

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

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

После того как пользователи с атрибутом 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 в качестве альтернативного идентификатора входа.

   

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

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

   

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

PowerShell

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

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

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

   Install-Module Microsoft.Graph
   

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

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

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

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

3. Проверьте, существует ли в клиенте homeRealmDiscoveryPolicy с помощью командлета Get-MgPolicyHomeRealmDiscoveryPolicy следующим образом:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

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

   Чтобы добавить HomeRealmDiscoveryPolicy в клиент, используйте New-MgPolicyHomeRealmDiscoveryPolicy командлет и задайте для атрибута AlternateIdLogin значение "Включено": 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"

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

Политика поэтапного развертывания позволяет администраторам клиентов включать функции для определенных групп 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. Найдите идентификатор каталогаObject для группы, добавляемой в политику поэтапного развертывания. Обратите внимание, что значение, возвращаемое для параметра 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. Интерфейс входа должен выглядеть и чувствовать себя так же, как вход с помощью имени участника-пользователя.

Устранить

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

1. Убедитесь, что оно было по крайней мере 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. Вход с помощью электронной почты в качестве альтернативного идентификатора входа будет выдаваться 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.

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