Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Azure AD Sync functionality

Copper Contributor

I just tested out the Azure AD Sync functionality to sync between a local AD domain and Azure AD.

What I gathered from reading through and setting it up is that in order to sync to Office365 or to a public domain (IE: OurDomain.com), we would need to change our internal AD domain users UPNs (OurDomain.local) to be the same as our external, public domain. Otherwise, without doing that, the internal (OurDomain.local) domain can only be synced to something like 'OurDomain.onmicrosoft.com', and it cannot be used for Office365 services, such as OneDrive. Now, we DO have our external domain listed as an alternative UPN and users can log into machines using username@OurDomain.com (They don't though - they log in as OurDomain\Username, which ends up username@OurDomain.local because the .local is the primary UPN). From what I gather, this isn't good enough and the public domain needs to be the primary UPN for the users.

 

There really is no way we could change all of our users from .local to .com, due to the way our users are spread out along with the way our data security is set up, tied to the .local UPNs, to try and change it would be quite the nightmare.

 

Given that the .local addresses can apparently be translated to something under the .onmicrosoft.com domain (Although for whatever reason, while the local accounts showed up in AzureAD, I couldn't log in with them - kept getting invalid credentials), what is the reason you can't translate the .local to your own .com, perhaps with the limitation that the name minus the .local or .com must match (IE: you can't to peaches.local to apples.com - it would have to be peaches.local to peaches.com or apples.local to apples.com)? Perhaps that is something that Microsoft might be able to look into implementing? In our case, being able to sync our local AD to AzureAD and/or Office 365 could be beneficial for the development we've been doing in Azure, and for Office365, the only thing we use is OneDrive, but everyone has obnoxious logins to it - It would be nice if they could log in with the same credentials as they use on their machines, but changing primary UPNs in our onsite AD just isn't an option.

2 Replies

Hi,

 

The reason you cannot use non-routable domain (.local) is because it cannot be verified that you own the domain. Being a public cloud, Microsoft need to verify if you really own the domain.

 

Best would have been if you could change the primary UPN. It doesn't impact normal logins etc. however since you have mentioned you can't do this, there must be a reason.

 

So, as an alternative you can use some other attribute to be used as O365/AAD login by doing custom installation of AAD connect. Refer "Azure AD sign-in configuration" section on below article.

 

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-star...

 

Not being a recommended practice there are limitations of doing so. Refer below link.

 

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-logi...

 

Give it a try and let us know. Always test before you put it in production!


@David Kramkowski wrote:

 

There really is no way we could change all of our users from .local to .com, due to the way our users are spread out along with the way our data security is set up, tied to the .local UPNs, to try and change it would be quite the nightmare.


What does that mean though? What have you designed and implemented on-prem that makes you incompatible with Office 365, and that can't be changed in any way?

 

Putting that another way, sometimes when customers say "we can't do this, so how can me make Microsoft/whoever work differently?" I get them to flip the question around. Imagine there's absolutely no way that Microsoft can make the .local domain work for you (you can't add a .local domain to your tenant because it can't be verified, and there's no workaround of "mapping" a .local to a verifiable domain), what is actually possible to change in your current environment to make things work?

 

If it's a "nightmare", so be it. It might be necessary.