Sign-in to Azure AD with email as an alternate login ID (still in Preview)

What will work?

Only emails in verified domains for the tenant are synchronized to Azure AD. Each Azure AD tenant has one or more verified domains, for which you have proven ownership, and are uniquely bound to you tenant.

One of the user attributes that’s automatically synchronized by Azure AD Connect is ProxyAddresses. If users have an email address defined in the on-prem AD DS environment as part of the ProxyAddresses attribute, it’s automatically synchronized to Azure AD. This email address can then be used directly in the Azure AD sign-in process as an alternate login ID.

Here’s what you need to know about email as an alternate login ID:

  • The feature is available in Azure AD Free edition and higher.
  • The feature enables sign-in with verified domain ProxyAddresses for cloud-authenticated Azure AD users.
  • When a user signs in with a non-UPN email, the unique_name and preferred_username claims (if present) in the ID token will return the non-UPN email.
  • The feature supports managed authentication with Password Hash Sync (PHS) or Pass-Through Authentication (PTA).
  • There are two options for configuring the feature:
    • Home Realm Discovery (HRD) policy – Use this option to enable the feature for the entire tenant. Global administrator privileges required.
    • Staged rollout policy – Use this option to test the feature with specific Azure AD groups. Global administrator privileges required.

What is not supported?

Some flows are currently not compatible with non-UPN emails, such as the following:

  • Identity Protection doesn’t match non-UPN emails with Leaked Credentials risk detection. This risk detection uses the UPN to match credentials that have been leaked. For more information, see Azure AD Identity Protection risk detection and remediation.
  • B2B invites sent to a non-UPN email are not fully supported. After accepting an invite sent to a non-UPN email, sign-in with the non-UPN email may not work for the guest user on the resource tenant endpoint.
  • When a user is signed-in with a non-UPN email, they cannot change their password. Azure AD self-service password reset (SSPR) should work as expected. During SSPR, the user may see their UPN if they verify their identity via alternate email.

How to enable?

Open Azure AD Connect blade and from User Sign-In choose “Email as alternate login ID”

And here enable Email as alternate. Bare in mind that if you enable this it will be enabled TENANT-WIDE.

Once users with the ProxyAddresses attribute applied are synchronized to Azure AD using Azure AD Connect, you need to enable the feature for users to sign in with email as an alternate login ID for your tenant. This feature tells the Azure AD login servers to not only check the sign-in identifier against UPN values, but also against ProxyAddresses values for the email address.

During preview, you can currently only enable the sign-in with email as an alternate login ID feature using PowerShell.

Changes made to the feature’s configuration in HRD policy are not explicitly shown in the audit logs. In addition, the Sign-in identifier type field in the sign-in logs may not be always accurate and should not be used to determine whether the feature has been used for sign-in.

Why to enable?

Many organizations want to let users sign in to Azure Active Directory (Azure AD) using the same credentials as their on-premises directory environment. With this approach, known as hybrid authentication, users only need to remember one set of credentials.

Some organizations haven’t moved to hybrid authentication for the following reasons:

  • By default, the Azure AD User Principal Name (UPN) is set to the same value as the on-premises UPN.
  • Changing the Azure AD UPN creates a mismatch between on-premises and Azure AD environments that could cause problems with certain applications and services.
  • Due to business or compliance reasons, the organization doesn’t want to use the on-premises UPN to sign in to Azure AD.
Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *