Office 365 + local domain .local and external .com shows Users will not be able to sign-in azure ad?

Occasional Contributor

We have office 365 premium.. i've set up our .com domain in the admin portal.. ran through the steps, except i did not add dns entries.. (we will do hybrid, both on site offsite for now, ie: exchange online for some, but not others for a short term).. i chose the skip for now option there.. it added the .com


When i run the azure AD sign-in configuration page.. it lists our domain.local domain as active directory upn suffix and on the right azure ad domain (still) says "Not added" (i thought would have appeared here after fixing the skip for now option on the portal).


At the bottom is says "users will not be able to sign-in azure ad using their on-premises credentials"




At this point i'm confused.. i thought adding the domain to office 365 was enough for it not to warn this..

Or.. do i need to do the powershell command i found on here to add an AD suffix.. though it looks like that command changes all existing to the new one? Wouldnt this be bad for users already logged in.. wouldnt it require they choose something different on next login (lose profile?).. how do we make this transparent and not affect the end users?


Thanks in advance



6 Replies

As long as you have the domain verified in O365, you will be able to sync the .com domain correctly. Of course, make sure that it's added as additional UPN suffix on-prem and the corresponding user attributes are changed to reflect the new suffix.


Thats the part i havent done is add the suffix using the powershell command.. i'm a bit nervous about running it.. doesnt it also change each user to the .com as the way to log in to their machines.. would they know its changed without me stating.. ie: i guess only if they log off and back onto their win 10 machines? Any chance this breaks anything onsite by making them use .com? IE: our local skype is using servername.domain.local for the pool at least.

Not sure which PowerShell cmdlet you are referring to, but adding the suffix in the AD Domains and Trust snap-in is harmless. Changing the user's UPN to reflect the new suffix will change the way they login to some applications, but the old domain\samaccountname method will continue to work.

Ah ok.. so either way no harm even with a brute force command line method?
I think either way, for single sign on to work as it should with exchange online later on, they all need to sign in via .com anyway.. so i'm guessing this is fine

Here is the article for the command line/powershell

I added the suffix to the domain.. refreshed the azure ad connect sign in page..


now it shows under ad upn suffix BOTH domain.local and domain.local under azure ad domain says not added.. and the says verified..


At the bottom it still says users will not be able to sign in using on premises creds.. unsure why though.. 

Probably because it detect the users with the .local suffix.