11-21-2018 07:53 AM
11-21-2018 07:53 AM
Hello and pardon the question if I missed the answer elsewhere.
We are finally migrating off on prem to O365. I would like to use pass through authentication but have questions about the UPN, public versus private domain. Let's say for example our public domain name for email is public.com and the internal AD domain is private.com AND we own both domain names. Our users email addresses are similar to firstname.lastname@example.org and the internal UPN is email@example.com. When setting up authentication since we own private.com and it is routable can we continue to use that for our user UPN or do we have to change it to firstname.lastname@example.org?
If we can continue to have users log in as email@example.com I have to add that private domain name to the domain list in O365 admin center, yes?
Finally, I got some confusing information form the tech who will be assisting us in the migration. He stated that he thought we have to maintain an exchange server on prem is we intend to ADFS or use pass though authentication - this is not correct is it?
11-21-2018 09:29 AM
11-21-2018 09:30 AM
11-21-2018 09:52 AM - edited 11-21-2018 10:17 AM
In an example I saw, the scenario was the organization had domain.com as their public domain and domain.local as their private AD domain. Obviously you cannot use a dot local domain outside your private AD environment. We on the other hand use public.com for email and private.com from AD and we own both domains. So my thought was that since I own it couldn't I just use private.com for O365 login? That is to say my users could still log in as firstname.lastname@example.org (on premises UPN) instead of email@example.com (Alternate ID) and only use the @public.com domain name for their email account e.g. firstname.lastname@example.org
11-21-2018 10:27 AM
Chris, thanks for your reply,
I think I found an article I was looking for. I skimmed this a couple weeks ago and then couldn't remember where I saw it. So yeah, should be OK based on this, I'll just have to add my private AD domain name to the list.
"Azure AD Connect synchronizes your users' UPN and password so that users can sign in with the same credentials they use on-premises. However, Azure AD Connect only synchronizes users to domains that are verified by Office 365. This means that the domain also is verified by Azure Active Directory because Office 365 identities are managed by Azure Active Directory. In other words, the domain has to be a valid Internet domain (for example, .com, .org, .net, .us, etc.). If your internal Active Directory only uses a non-routable domain (for example, .local), this can't possibly match the verified domain you have on Office 365. You can fix this issue by either changing your primary domain in your on premises Active Directory, or by adding one or more UPN suffixes."
11-21-2018 10:58 AM
Second question re. your reply - keeping an exchange server on prem, it's just acting as a management console basically since non of the mail data is stored locally nor does it pass through that server, correct? So I could set up a tiny VM with just Exchange whatever version installed and not have to worry about space for the data, nor CALs since the client licenses are now O365?
11-21-2018 11:02 AM
11-27-2018 11:46 AM
We're licensed for Business Essentials, not E3 or better, so I don't think I can use the free key. I have an entitlement to on prem Exchange 2016 though, but not enough CALs for every user at that level. I'll have to investigate my options further. It may wind up we elevate to E3.
11-27-2018 11:48 AM
11-27-2018 11:50 AM
Excellent! That's what I was just trying to look up. I got very confusing info about that from the tech were are using to assist.
Thank you very much
11-27-2018 11:55 AM
11-27-2018 12:00 PM
OK. We are maintaining an on prem AD environment so should have more than enough Windows Server CALs for that purpose.