9m48y (9m48y) asked a question.
Federating O365 primary domain with Okta
I am looking for clarification on federating O365 in Okta. I am told you can not federate your "primary" domain. Meaning what you have set as primary in O365. We are hyrid and use Azure connect to sync on prem AD to Azure AD. The onmicrosoft.com domain is not set as our primary as our email routeable domain is our on prem domain, the one we obviousbly want to federate with Okta. I cant just change my priamry domain in O365 or I will break mail flow. Is there no way around this? I am told when I try to federate from okta that MS will reject the command as it will see the domain I want to federate as primary. What are my options?
In your O365 tenant you simply set your onmicrosoft.com domain as default.
This will not affect your mail flow as the default domain determines what the mail suffix is for newly created mail account when created manually within O365.
However, once you federate a domain, you'll find it is removed from the domain dropdown within the tenant itself for new user creation. That is by design though as federated domains are intended to have accounts mastered in on prem solutions and then synchronized to O365, whether it be through Azure AD DS, or Okta, or another integration suite.
I think there is more to it then that. Setting the default domain also determins login name/UPN, as well as users OneDrive. Right now, I am not able to login with the onmicrosoft.com alias. I think you can only login with "default" username. So by changing the default domain, it sounds to me like I would be locking everyone out until they login with the @onmicrosoft.com email. I am hoping to find a customer that has their O365 default domain set as the exact domain they want to federate in Okta. You would think Okta would know more about this, but all I get is "change your default domian".
I have federated 5 domains on 3 tenants with okta in the last two weeks, all tenants got their default domain set to their tenant domain. All users are now logging to O365 with their user.name@primary.comain addresses and not their @onmicrosoft.com addresses.
The onmicrosft ones are tenant only logins, they will flow through the MS auth flow for the tenant and any MFA requirements setup on the tenant itself. These are useful to administrators as it allows administrators to still access the tenant in the event an Auth provider is down or cannot be reached.
Once a domain is federated when user goes to portal.office.com or office.com and initiates a login, if the domain matches one that has been federated they are then directed to the auth provider login process in our case Okta. There they will flow though the sign in policies and app rules configured for them.
Again if you tenant only two domains (the onmicrosoft.com one and your organization domain) you will want to move the default domain setting to the onmicrosoft.com, this will allow your other one to be federated. As Microsoft does not let you federate your default domain, and the onmicrosoft one cannot be federated at all it is common practice to leave it as the default domain if you plan to federate your other one.
If you have the means to set up an additional test domain on your tenant, and confirm it with Microsoft you can federate that one first, and use MSonline PowerShell modules to confirm the federation status changes and how the activelogonuri changes afterwards. At which point you can go to office.com and initiate a login as test@[yourtestdomain] and see it switch over to okta for login even if that user doesnt exist, because at that point it is up to the okta auth to determine if its a valid or invalid login.
I totally understand I am not able to federate with my “default” domain and to use Okta with O365, I would have to change my default domain. So to confirm, you are saying that I can change my default domain to the onmicrosoft.com domain in O365, but not have to change existing users on prem Active Directory UPN? Username is still going to be first.last@mydomain.com? I understand onmicrosoft accounts are only o365 accounts and we only use them for admin roles. I am not worried about those accounts. I am concerned with AD synced accounts that all use @mydomain.com for OneDrive, Exchange, SharePoint etc.
I am reading posts that say different things and I am trying to confirm what happens by changing your default domain. Right now I am not able to login with any other alias other then what is my default domain account. Meaning I cant login to office.com with my @onmicrosoft.com email alias. So my concern is if I change that to be my default domain, I would assume I can no longer login with @mydomain.com email.
My understanding is that your UPN has to match what is set as your default domain. If my UPN changes, then all my Okta usernames change as well. I am not concerned with Okta/o365 working, I know that part will. I am concerned about the pieces that break by changing my default domain in O365.
I obviously do not know your tenant or environment like I do my own. I will say that in my experience you cannot login as an alias as they allow for sending and receiving mail under that address after you are authenticated with your actual login. changing he
For my users prior to federating, I run an export and locate any users whose UPN domain does not match the domain I am going to federate and correct them. I then allow that change to replicate to azure and verify. (Normally at this same time I take the
opportunity to have front part their UPN match their email as closely as possible if they are vastly different. That way I can communicate at after the change they should login with their email and not have to explain the difference.)
Once those changes are made, I check the status of their domains to determine which one is set to in O365 admin center. If it is the one I will be federating though Okta,MS, or another service I will set the onmicrosft.com domain to be the default one. If going through the azure AD portal, it would be under custom domains and set to primary.
You could also get it through Powershell with "Get-AzureADDomain | Select-Object -Property Name,AuthenticationType,IsDefault"
I then initiate the federation process through Okta in most cases otherwise I would manually do it through PowerShell. Things to note though changing of the UPN after federation may need a user to sign in and out of office for the account change to take effect in their software. I have gone through this process on two tenants and will do it again on a third, and fourth one in the coming weeks.
As always you could open support cases with Microsoft and Okta and have them scope the impact to your environment with you prior to federating, some accounts may still need basic auth, or accounts that use older software that cannot use modern auth or tokens. That will be disallowed by Okta default app policies.
I do have two tickets open with MS, and cant seem to get an answer from MS or Okta support. I still dont know what happens when I change the default domain in O365. I dont understand how anyone would want to change their default domain to something that is not their default domain, and that this is the only way to make it work with Okta. How is this acceptable? I am going round and round and not getting a clear answer on what happens to user accounts with a change like this.
Hopefully MS doesn't drag their feet too much and can escalate to the right perons. User accounts should not be impacted as their accounts and UPNs do not change when the primary domain of a tenant changes.
Per Microsoft: The primary domain is the default domain name for a new user when you create a new user. Setting a primary domain name streamlines the process for an administrator to create new users in the portal. You can change the primary domain name for your organization to be any verified custom domain that isn't federated. Changing the primary domain for your organization won't change the user name for any existing users.
Another good read is: How UPN changes affect OneDrive - OneDrive | Microsoft Docs
This outlines what happens when you change a UPN of a user that is already logged in and using their account when the change take effect. Again, though changing the primary domain won't change any existing users.
Ok so the UPN/User login doesnt change for existing users, ok great. So for new users, its going to automatically create the new user with the new domain. I get that. I guess I need to find out how that works since my users are created on prem and sync to azure. Right now you cant modify a user name in Azure or O365 since it's syncing from on prem. So it sounds like if I did change my default domain in O365, and users are not created IN O365, that maybe nothing will actually change. That is what I need a confirmed answer on.
Sync will function how it always has. It will sync your users with the UPN configured in their on prem profile. Their on prem profile is the source of truth. Once federated, a synchronized profile is the only to create a user with a UPN matching that domain. You will no longer be able to select it from a tenant mastered profile.
For anyone going through this. I have confimed that changing the default domain in O365 to a domain that really isnt your default, so you can federate Okta, is not that big a deal, if you create all your users and groups on prem AD and sync. It does only affect users and groups created in O365, which for us, would only be Teams groups. And that is ok if they get created with the onmicrosoft.com domain as there is no external mail to and from a teams group. If you create a user in Azure, you simple just have to change the drop down to your actual domain, as the "default" will just appear first. Not that big a deal even if you do create all your users in Azure/O365. So changing your default domain in O365 only changes the default SMTP for any user or group created in O365, but that doesnt mean it cant be changed back to your actual domain. It might just be ab extra step you didnt have before. Not ideal, but not terrible. Hope that helps someone going through this.