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

Примечание

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

Многие организации хотят разрешить пользователям входить в Azure Active Directory (Azure AD), используя те же учетные данные, что и в их локальной среде каталогов. При таком подходе, известном как гибридная проверка подлинности, пользователям нужно запоминать только один набор учетных данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ведение журнала. Изменения, внесенные в конфигурацию функции в политике HRD, не отображаются в журналах аудита явным образом. Кроме того, поле Sign-in identifier type (Тип идентификатора входа) в журналах входа может не всегда отображать точные результаты. Его не следует использовать для того, чтобы определить, применялась ли эта функция для входа.

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

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

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

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

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

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

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

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

Типичным решением этой проблемы является установка для UPN Azure AD адреса электронной почты, с которым пользователь должен войти. Этот подход работает, хотя приводит к разным UPN между локальным доменом приложения и Azure AD, и эта конфигурация не совместима ни с одной из рабочих нагрузок Microsoft 365.

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

Другой подход — синхронизировать имена участников-пользователей Azure AD и локальные имена с одним и тем же значением, а затем настроить Azure AD, чтобы разрешить пользователям входить в Azure AD с помощью проверенного адреса электронной почты. Чтобы предоставить эту возможность, необходимо определить один адрес электронной почты или несколько в атрибуте пользователя ProxyAddresses в локальном каталоге. Затем ProxyAddresses автоматически синхронизируются с Azure AD с помощью Azure AD Connect.

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

Синхронизация адресов электронной почты для входа в Azure AD

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

Для поддержки такого подхода к гибридной проверке подлинности следует синхронизировать локальное окружение AD DS с Azure AD с помощью Azure AD Connect и настроить ее для использования PHS или PTA. Дополнительные сведения см. в статье Выбор правильного метода аутентификации для решения гибридной идентификации Azure AD.

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

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

Важно!

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

Дополнительные сведения см. в статье Добавление и проверка пользовательского доменного имени для облачной службы Azure.

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

Примечание

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

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

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

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

    Install-Module AzureADPreview
    

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

  2. Войдите в клиент Azure AD от имени глобального администратора с помощью командлета Connect-AzureAD:

    Connect-AzureAD
    

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

  3. Убедитесь, что HomeRealmDiscoveryPolicy уже существует в клиенте, использовав командлет Get-AzureADPolicy следующим образом.

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    
  4. Если политика в настоящее время не настроена, команда не возвращает ничего. Если возвращается политика, пропустите этот шаг и перейдите к следующему шагу, чтобы обновить существующую политику.

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

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

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

    Id                                   DisplayName                 Type                     IsOrganizationDefault
    --                                   -----------                 ----                     ---------------------
    5de3afbe-4b7a-4b33-86b0-7bbe308db7f7 BasicAutoAccelerationPolicy HomeRealmDiscoveryPolicy True
    
  5. Если настроенная политика уже существует, проверьте, включен ли атрибут  AlternateIdLogin , как показано в следующем примере выходных данных политики:

    Id : 5de3afbe-4b7a-4b33-86b0-7bbe308db7f7
    OdataType :
    AlternativeIdentifier :
    Definition : {{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}}
    DisplayName : BasicAutoAccelerationPolicy
    IsOrganizationDefault : True
    KeyCredentials : {}
    Type : HomeRealmDiscoveryPolicy
    

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

    Важно!

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

    В следующем примере добавляется атрибут  AlternateIdLogin и сохраняется атрибут  AllowCloudPasswordValidation, который мог быть уже установлен:

    $AzureADPolicyDefinition = @(
      @{
         "HomeRealmDiscoveryPolicy" = @{
            "AllowCloudPasswordValidation" = $true
            "AlternateIdLogin" = @{
               "Enabled" = $true
            }
         }
      } | ConvertTo-JSON -Compress
    )
    $AzureADPolicyParameters = @{
      ID                    = "b581c39c-8fe3-4bb5-b53d-ea3de05abb4b"
      Definition            = $AzureADPolicyDefinition
      DisplayName           = "BasicAutoAccelerationPolicy"
      IsOrganizationDefault = $true
      Type                  = "HomeRealmDiscoveryPolicy"
    }
    
    Set-AzureADPolicy @AzureADPolicyParameters
    

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

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    

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

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

Примечание

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

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

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

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

    Install-Module AzureADPreview
    

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

  2. Войдите в клиент Azure AD от имени глобального администратора с помощью командлета Connect-AzureAD:

    Connect-AzureAD
    

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

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

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

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

    Get-AzureADMSGroup -SearchString "Name of group to be added to the staged rollout policy"
    
  6. Добавьте группу в политику поэтапного развертывания, как показано в следующем примере. Замените значение в параметре -Id на возвращенное значение для идентификатора политики из шага 4, а значение параметра -RefObjectId — на параметр Id, записанный на шаге 5. Может потребоваться до одного часа, прежде чем пользователь в группе сможет войти в Azure AD с помощью адреса электронной почты в качестве альтернативного имени для входа.

    Add-AzureADMSFeatureRolloutPolicyDirectoryObject -Id "ROLLOUT_POLICY_ID&quot; -RefObjectId &quot;GROUP_OBJECT_ID"
    

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

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

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

Remove-AzureADMSFeatureRolloutPolicyDirectoryObject -Id "ROLLOUT_POLICY_ID&quot; -ObjectId &quot;GROUP_OBJECT_ID" 

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

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

Set-AzureADMSFeatureRolloutPolicy -Id "ROLLOUT_POLICY_ID" -IsEnabled $false 
Remove-AzureADMSFeatureRolloutPolicy -Id "ROLLOUT_POLICY_ID"

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

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

Диагностика

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

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

  2. Если используется политика HRD, убедитесь, что в HomeRealmDiscoveryPolicy Azure AD для свойства определения AlternateIdLogin установлено значение "Enabled": true, а для свойства IsOrganizationDefault — True:

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    

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

    Get-AzureADMSFeatureRolloutPolicy
    
  3. Убедитесь, что в учетной записи пользователя задан адрес электронной почты для атрибута ProxyAddresses в Azure AD.

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

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

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

    Install-Module AzureADPreview
    

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

  2. Войдите в клиент Azure AD от имени глобального администратора с помощью командлета Connect-AzureAD:

    Connect-AzureAD
    
  3. Получить затронутых пользователей.

    # Get all users
    $allUsers = Get-AzureADUser -All $true
    
    # 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
    

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

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

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