Considerations regarding Azure AD Connect and Hybdrid identitys

[SamirAbdou1999]

Im responsible for migrating our work's onprem enviorment to Azure.

Our onprem enviroment have an domain name of lets say " onpremdomain.com " 

Our Office365 domain tennant is " companynamex.com " but however, this tenant is nothing i have administrativ control over more than my own personal office365 own. I can't log in into portal.office.com and administrate the cloud users.

Let's say i install Azure AD Connect on our onprem domain controller and sync all our local users to the Azure AD Domain Services. Purpose of this would be if i want my local users to be cloud managed instead and maybe even add an Office365 licens to the users that once were based on my onprem DC?

Note, its two different domains and preferbly all users in the future only want 1 sign-in (same on pc and office365)

What should i do and do i have permissions to do this ?

[#2]

also the problem with syncing onprem users to the azure ad and giving them an new office365 licens is that i will have the wrong domain name...

since my local AD does NOT have the same name as the Azure AD.

[#3 · Accepted solution]

An alternate UPN suffix can be added to Windows AD.  All users replicated to Azure AD will need the UPN Suffix changed to the alternate suffix before replicating the accounts with Azure AD.  Use the IdFIx tool to verify consistency before replicating.  As an alternative, you could add your Windows AD domain to Azure AD and continue using that domain.

Also, you will need and account with Global Admin rights to the Azure AD tenant to setup AD Connect.

[#4]

Thanks for reply @Travis Roberts 

Do i need to swap the old UPN Suffix to the new one before doing the synchronization?

I'll check out IDFIX aswell.

Am i able to use Single sign on/password sync even though its different identities?

[#5]

@SamirAbdou1999 Hello,

You do need to add the alternate UPN suffix to Windows AD and then update all users that will sync to the new UPN.  

Single-sign on will work.  This is a common scenario with organizations that have non-routable Windows domains (domain.local).  Although both your domains are routable, the same principles apply. 

https://docs.microsoft.com/en-us/microsoft-365/enterprise/prepare-a-non-routable-domain-for-director...