Enable user-friendly sign-in to Azure AD with email as an alternate login ID

[Alex Simons (AZURE)]

Howdy folks,

Today we’re announcing the public preview of the ability to sign-in to Azure AD with email in addition to UPN (UserPrincipalName). In organizations where email and UPN are not the same, it can be confusing for users when they can't use their familiar email address to sign-in. With this preview capability, you can enable your users to sign in with either their UPN or their email address, helping them avoid this confusion.

This feature can be enabled by setting the AlternateIdLogin attribute in the HomeRealmDiscoveryPolicy. Please use the instructions in our documentation to set this up in your organization.

Some customers are using capabilities in Azure Active Directory (Azure AD) Connect to achieve this today, but that requires them to set the email address as the UPN in Azure AD. With this preview capability, you can now use the same UPN across on-premises Active Directory and Azure AD to achieve the best compatibility across Office 365 and other workloads, while still allowing your users to sign in with either their UPN or email, further simplifying their experience.

We hope this change simplifies the sign-in experience for your end users.

As always, we’d love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below or on the Azure AD feedback forum. 

Stay safe and be well,

Alex Simons (@Alex_A_Simons)

Corporate VP of Program Management

Microsoft Identity Division

[Abdul Farooque]

@Alex

Cool!!! much awaited feature...

So I f I use UPN to sync my users but their SMTP is different, still my users can login to azure/office 365 with their SMTP email id, right?

Do I must sync my email domain to accomplish this or just verify the domain in office 365 ?

[diogocatossi]

Great news! It's always good to make user's lives easier and simplified! 

[Tomerlevin]

Agreed much awaited feature. Thanks for making it happen

[patrick410]

Hello Alex, does this function work when logging in O365 connected workstations?

[belaie]

This is nice feature, but in our azuread , our primary email addresses on users are very long and are generated based on user full names for users its more convenient to login with UPN which is based on users' usernames. It would be cool if all Microsoft login screen text should say "username" not an email address to log in, which would help users following company's internal username policy  (email or UPN) to login to the cloud services.

[Jerry Evangelista]

Thanks for releasing this AAD Team! It is huge for companies that do not have matching UPNs and email addresses.

[hobbycat]

@Alex

This is great news and will benefit many of us.

I implemented this in a non-production environment yesterday, on the whole it went well. However, it uncovered something that I would like clarity on, if there is contention between a UPN (cloud only account) and a proxy/email address on a sync'd account for example - which will take precedence? This is not a situation that I was expecting to encounter but it existed. From some the limited testing, it appears the account with email address wins, whereas I would have expected the UPN to take precedence.

There was also a delay of upwards 20 minutes from creating the policy to seeing the change in behaviour. If this is expected then it would be helpful if the documentation reflected this.

[pmahlmann]

we need this as we are doing a domain migration but are affected by duplicate UPNs in both domains which blocks domain trust routing.  This feature will allow us to change the UPN in one domain and then use email to log into Azure/Office365.  when will this be GA.

[nateweso]

Keeping the sign-on ID separate from the email address is better from a security perspective IMO.

My organization is frequently the target of password guessing attacks, with email addresses used for the login name.  Keeping the "private" sign-in ID separate from your "public" email address adds another layer of protection.

[Chris Smith]

Good morning @Alex Simons (AZURE) , we've implemented this new policy as per the instructions and we have checked the three boxes for troubleshooting, but still not operating. Since this is public preview, is there someone we can talk to for troubleshooting or discussing further? Or should we attempt to open a ticket on this, or just wait and try again later?  After typing the new identifier (alternate ID/proxy address) in the AAD username field, it responds with "This username may be incorrect. Make sure you typed it correctly. Otherwise, contact your admin." This is with an alternate email address suffix that is a verified domain in our AAD tenant setup, so I believe we have everything we needed for this. Would there be a delay of any kind? 

Very excited about this new feature, many thanks!

[Chris Smith]

After my post above, it is now working, so it looks like there was just some delay in implementation (30-35 minutes) for future adventurers that might be looking through these threads for input. :) It was a super simple change, just took a small amount of time (would recommend to update documentation - I'll comment on that article as well).  Thanks again, such a great feature!

[Joey Cruz]

@Abdul Farooque - So If I use UPN to sync my users but their SMTP is different, still my users can login to azure/office 365 with their SMTP email id, right?

Yes, users will have the option to use UPN or SMTP Proxy Address. Which ever is easiest for the user.   

Do I must sync my email domain to accomplish this or just verify the domain in office 365 ?

You would need to verify the domain in Azure AD for the Proxy address to by synced to the user object.

To get a full list of requirements and limitations review our docs here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-use-emai... 

@patrick410  - does this function work when logging in O365 connected workstations?

I will provide an update on this question. 

@belaie  - It would be cool if all Microsoft login screen text should say "username" not an email address to log in, which would help users following company's internal username policy  (email or UPN) to login to the cloud services.

This is a great suggestions for us to consider, would love for you to add this suggestion to our user voice :

https://feedback.azure.com/forums/169401-azure-active-directory

@hobbycat - However, it uncovered something that I would like clarity on, if there is contention between a UPN (cloud only account) and a proxy/email address on a sync'd account for example - which will take precedence? This is not a situation that I was expecting to encounter but it existed. From some the limited testing, it appears the account with email address wins, whereas I would have expected the UPN to take precedence.

I will provide an update on this question. 

There was also a delay of upwards 20 minutes from creating the policy to seeing the change in behaviour. If this is expected then it would be helpful if the documentation reflected this.

Yes, this is expected to take up to 1 hour to see expected behavior. We will update our documentation to include this note. thank you 

@pmahlmann  - This feature will allow us to change the UPN in one domain and then use email to log into Azure/Office365.  when will this be GA.

We are looking to get a much customer feedback during preview before going GA. We do not have a target date currently.

@Chris Smith  - It was a super simple change, just took a small amount of time (would recommend to update documentation - I'll comment on that article as well).  Thanks again, such a great feature!

Thank you for the feedback, will be adding this to our documentation. 

Joey Cruz - Program Manager - Identity Engineering Team  

[FernandoV_RTX]

I agree with @nateweso, using email addresses as login names has always been a stupid idea and a big security hole. Now malicious attacks need simply to use easily accessible or leaked email addresses to spray attack looking for vulnerable accounts. Way to go Microsoft.

[Alexey Goncharov]

How the new change will affect MFA registered for a user?

[Joey Cruz]

@Alexey Goncharov  - How the new change will affect MFA registered for a user?

This will not affect MFA registration, users will be able to go through the same registration flow. Once the users signs-in, the user will see their UPN in the registration flow and in the Authenticator App (if registered). We will make note in the documentation to include a note.

[AndreasMarx]

@Joey Cruz 

Any update on the behaviour described by @hobbycat :

- However, it uncovered something that I would like clarity on, if there is contention between a UPN (cloud only account) and a proxy/email address on a sync'd account for example - which will take precedence? This is not a situation that I was expecting to encounter but it existed. From some the limited testing, it appears the account with email address wins, whereas I would have expected the UPN to take precedence.

I will provide an update on this question. 

I faced the same issue. EMail address takes precedence over UPN. Is this expected? Can that be changed?

[Alexey Goncharov]

Thank you @Joey Cruz. So, if I understood it correctly, the Authenticator app and FIDO2 token registered as 2FA for a user, will  to leverage a UPN of an account, rather than one of the smtp aliases used by a user for authentication, right? 

[Joey Cruz]

@AndreasMarx  - I faced the same issue. EMail address takes precedence over UPN. Is this expected? 

Will follow up for clarification. 

@Alexey Goncharov  - Thank you @Joey Cruz. So, if I understood it correctly, the Authenticator app and FIDO2 token registered as 2FA for a user, will  to leverage a UPN of an account, rather than one of the smtp aliases used by a user for authentication, right? 

Correct, the UPN will be used. 

[freds123]

nice, thanks MS.

Regarding the security part, I think its pretty easy to spray and guess internal usernames of a company from attacker's perspective. The benefits probably out weight the cons for an org.

[Joey Cruz]

@hobbycat - However, it uncovered something that I would like clarity on, if there is contention between a UPN (cloud only account) and a proxy/email address on a sync'd account for example - which will take precedence? This is not a situation that I was expecting to encounter but it existed. From some the limited testing, it appears the account with email address wins, whereas I would have expected the UPN to take precedence.

@AndreasMarx  - I faced the same issue. EMail address takes precedence over UPN. Is this expected? 

@AndreasMarx This is expected behavior.  Having duplicate ProxyAddress or UserPrincipalsNames will be surfaced in the Connect Health dashboard. We recommend reviewing the following documentation: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-health-diagnose-sync-e...

[RickardD]

Can we get the same feature in ADFS for federated domains?

[Joey Cruz]

@RickardD  - Can we get the same feature in ADFS for federated domains?

ADFS offer the ability to use Alt-id, we recommend reviewing the following documentation : https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-logi...

[dmontewis]

Hi, thanks for this new feature.

It doesn't work for me, i activated this feature in Azure AD policy as describe in the documentation.

The user proxy address attribute is well replicated from AD on-prem to Azure AD.

However, it doesn't work when i try to connect to https://myprofile.microsoft.com/, my email address isn't recognized...

Do you have any idea ?

Thank you !

[Joey Cruz]

 @dmontewis - It doesn't work for me, i activated this feature in Azure AD policy as describe in the documentation.

Please allow a couple of hours for the policy to be effective and re-attempt. 

[dmontewis]

@Joey Cruz 

Thanks for the advice but the policy was activated several weeks ago..

Regards

[Joey Cruz]

@dmontewis - from our follow up discussion we identified that "-IsOrganizationDefault $true" was not set. This is a requirement for the HRD policy to take effect. 

[Jonathan Works]

Hi @Joey Cruz - Are there any planned requirements for licensing this feature under Azure AD Premium or is this going to be a feature available for free with the standard Azure AD license?

Also, can we disable the feature on specific custom SMTP domains that we won't want the users logging in with?

[calvinhklui]

@Jonathan Works 

Are there any planned requirements for licensing this feature under Azure AD Premium or is this going to be a feature available for free with the standard Azure AD license?

No licensing requirement is currently planned. 

Also, can we disable the feature on specific custom SMTP domains that we won't want the users logging in with?

Currently, you can not disable per SMTP. We are working on the ability to roll this feature out to specific groups.

[JeffL175]

We have alternate login configured with ADFS today through domain federation.  If we were to turn on this option, would you expect that users would still be redirected to ADFS until the federation setting is changed for that domain or will this configuration override that?

[calvinhklui]

@JeffL175 This feature only works for managed domains and does not interfere with your federation settings.

[Ben Stegink]

Any ideas/plans yet on when this might come out of preview?

Thanks,

Ben

[JeffL175]

Our organization has been using this feature since my last post in September without issue.  We've been able to decommission our ADFS as a result, one less entry point.  I will say when we first turned it on, the feature was not overriding our federation settings to ADFS.  A  week or so later when we were about to turn it on for all domains, we realized that our ADFS had been getting zero logins for a few days.  This suggested to us the behavior did change and we unknowingly had put our entire org into scope without a single support call (~3500 users) so we completed the config for all domains and haven't looked back since.

[nj28sharp]

We have been testing Cloud Azure MFA with on premise 2019 ADFS server using AlternateID  mail, it works if we want to use Azure MFA as primary login, but fails Additional Cloud Azure MFA as secondary.   Once we removed the alternateid it works. 

[calvinhklui]

@Ben Stegink We don't have an ETA yet but we are planning for this feature's GA release.

@nj28sharp This feature only works with Azure AD authentication. For federated domain users, Home Realm Discovery will not perform email lookup and instead redirect users to authenticate with their federation.

[MrKnazure]

@calvinhklui

Any news about ETA for GA release for this feature?

Christian

[calvinhklui]

@MrKnazure We are still planning for this feature's GA release. Please refer to our documentation for the latest information about the feature.

[Eiba Haddad]

Any idea if Azure AD Sign-ins report can show an indication of using this feature. 

[calvinhklui]

@Eiba Haddad In the Sign-in logs, the Sign-in identifier field shows the value inputted by the user on the sign-in page.

[Eiba Haddad]

Thanks @calvinhklui . There doesn't seem to be an reference to a "sign-in identifier" in the article you shared. Can you please point me to it.

I can only see the username in the logs which shows the UPN value regardless of which alias was used to login. 

[calvinhklui]

@Eiba Haddad If you select an item in the list view, under the Basic info tab, there should be a Sign-in identifier field. This field was previously named Alternate sign-in name.

[Eiba Haddad]

@calvinhklui Are you able to provide a screenshot of such information? is this only available on a certain private preview of this feature?

[calvinhklui]

@Eiba Haddad Here's a screenshot. Hope this helps! The Sign-in identifier field should be available in the Azure Portal for all tenants.

[Eiba Haddad]

thanks @calvinhklui . that works, I am able to see that field being populated when email as an alternate login ID is being used.

I am wondering if you happen to know about this feature causing issues with evaluating some conditional access policies with grant control that requires domain-joined device.

I am noticing that Device state is resolving to Unregistered which is resulting in Grant Control being "Not satisfied". Could this be due to Azure AD PRT not getting obtained while using email as an alternate login ID ?

[calvinhklui]

@Eiba Haddad Email as an Alternate Login ID does not currently support Hybrid Azure AD Join, Azure AD Join, or Azure AD device registration so it shouldn't cause any issues with Conditional Access.

[harabajian]

Anyone experiencing issues signing in to admin.microsoft.com with their email address as alternate login ID? 

We are sorry, something went wrong. Please try refreshing the page in a few minutes. If the problem persists, please visit status.office.com for updates regarding known issues. Ref A: C687D5F58ECD4E7BB56FFBC0F02B267E Ref B: LAX311000113051 Ref C: 2021-07-15T16:06:46Z

[Eiba Haddad]

Any idea when this feature will become generally available. It has been in public preview for 14 months.

[PaulMJClark]

I would also like to know when this is due to become generally available. I also can't find it at all at https://azure.microsoft.com/en-us/updates/?status=nowavailable,inpreview can anyone help with this. We would like to utilise this in Production but NOT until it becomes General Release.

[TrentStephens]

Any recent details regarding this moving to GA?