Tutorial: Migrate Okta federation to Microsoft Entra ID-managed authentication
In this tutorial, learn to federate Office 365 tenants with Okta for single sign-on (SSO).
You can migrate federation to Microsoft Entra ID in a staged manner to ensure a good authentication experience for users. In a staged migration, you can test reverse federation access to remaining Okta SSO applications.
Note
Scenario described in this tutorial is only one possible way of implementing the migration. You should try to adapt the information to your specific setup.
Prerequisites
- An Office 365 tenant federated to Okta for SSO
- A Microsoft Entra Connect server or Microsoft Entra Connect cloud provisioning agents configured for user provisioning to Microsoft Entra ID
- One of the following roles: Global Administrator, Application Administrator, Cloud Application Administrator, or Hybrid Identity Administrator.
Configure Microsoft Entra Connect for authentication
Customers that federate their Office 365 domains with Okta might not have a valid authentication method in Microsoft Entra ID. Before you migrate to managed authentication, validate Microsoft Entra Connect and configure it for user sign-in.
Set up the sign-in method:
- Password hash synchronization - an extension of the directory synchronization feature implemented by Microsoft Entra Connect server or cloud-provisioning agents
- Use this feature to sign in to Microsoft Entra services like Microsoft 365
- Sign in to the service with the password to sign in to the on-premises Active Directory instance
- See, What is password hash synchronization with Microsoft Entra ID?
- Pass-through authentication - sign in to on-premises and cloud applications with the same passwords
- When users sign in through Microsoft Entra ID, the pass-through authentication agent validates passwords against the on-premises AD
- See, User sign-in with Microsoft Entra pass-through authentication
- Seamless SSO - signs in users on corporate desktops connected to the corporate network
- Users have access to cloud applications without other on-premises components
- See, Microsoft Entra seamless SSO
To create a seamless authentication user experience in Microsoft Entra ID, deploy seamless SSO to password hash synchronization or pass-through authentication.
For prerequisites of seamless SSO see, Quickstart: Microsoft Entra seamless single sign-on.
For this tutorial, you configure password hash synchronization and seamless SSO.
Configure Microsoft Entra Connect for password hash synchronization and seamless SSO
On the Microsoft Entra Connect server, open the Microsoft Entra Connect app.
Select Configure.
Select Change user sign-in.
Select Next.
Enter the credentials of the Global Administrator of the Microsoft Entra Connect server.
The server is configured for federation with Okta. Change the selection to Password Hash Synchronization.
Select Enable single sign-on.
Select Next.
For the local on-premises system, enter the domain administrator credentials.
Select Next.
- On the final page, select Configure.
- Ignore the warning for Microsoft Entra hybrid join.
Configure staged rollout features
Tip
Steps in this article might vary slightly based on the portal you start from.
Before you test defederating a domain, in Microsoft Entra ID use a cloud authentication staged rollout to test defederating users.
Learn more: Migrate to cloud authentication using Staged Rollout
After you enable password hash sync and seamless SSO on the Microsoft Entra Connect server, configure a staged rollout:
Sign in to the Microsoft Entra admin center as at least a Hybrid Identity Administrator.
Browse to Identity > Hybrid management > Microsoft Entra Connect > Connect Sync.
Confirm Password Hash Sync is enabled in the tenant.
Select Enable staged rollout for managed user sign-in.
After the server configuration, Password Hash Sync setting can change to On.
Enable the setting.
Seamless single sign-on is Off. If you enable it, an error appears because it's enabled in the tenant.
Select Manage groups.
Add a group to the password hash sync rollout. In the following example, the security group starts with 10 members.
Wait about 30 minutes for the feature to take effect in your tenant.
When the feature takes effect, users aren't redirected to Okta when attempting to access Office 365 services.
The staged rollout feature has some unsupported scenarios:
- Legacy authentication protocols such as POP3 and SMTP aren't supported.
- If you configured Microsoft Entra hybrid join for Okta, the Microsoft Entra hybrid join flows go to Okta until the domain is defederated.
- A sign-on policy remains in Okta for legacy authentication of Microsoft Entra hybrid join Windows clients.
Create an Okta app in Microsoft Entra ID
Users that converted to managed authentication might need access to applications in Okta. For user access to those applications, register a Microsoft Entra application that links to the Okta home page.
Configure the enterprise application registration for Okta.
Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
Browse to Identity > Applications > Enterprise applications > All applications.
Select New application.
Select Create your own application.
On the menu, name the Okta app.
Select Register an application you're working on to integrate with Microsoft Entra ID.
Select Create.
Select Accounts in any organizational directory (Any Microsoft Entra Directory - Multitenant).
Select Register.
On the Microsoft Entra ID menu, select App registrations.
Open the created registration.
- Record the Tenant ID and Application ID.
Note
You need the Tenant ID and Application ID to configure the identity provider in Okta.
- On the left menu, select Certificates & secrets.
- Select New client secret.
- Enter a secret name.
- Enter its expiration date.
- Record the secret value and ID.
Note
The value and ID don't appear later. If you don't record the information, you must regenerate a secret.
On the left menu, select API permissions.
Grant the application access to the OpenID Connect (OIDC) stack.
Select Add a permission.
Select Microsoft Graph
Select Delegated permissions.
In the OpenID permissions section, add email, openid, and profile.
Select Add permissions.
Select Grant admin consent for <tenant domain name>.
Wait for the Granted status to appear.
On the left menu, select Branding.
For Home page URL, add your user application home page.
In the Okta administration portal, to add a new identity provider, select Security then Identity Providers.
Select Add Microsoft.
On the Identity Provider page, enter the Application ID in the Client ID field.
Enter the client secret in the Client Secret field.
Select Show Advanced Settings. By default, this configuration ties the user principal name (UPN) in Okta to the UPN in Microsoft Entra ID for reverse-federation access.
Important
If UPNs in Okta and Microsoft Entra ID don't match, select an attribute that's common between users.
Complete autoprovisioning selections.
By default, if no match appears for an Okta user, the system attempts to provision the user in Microsoft Entra ID. If you migrated provisioning away from Okta, select Redirect to Okta sign-in page.
You created the identity provider (IDP). Send users to the correct IDP.
On the Identity Providers menu, select Routing Rules then Add Routing Rule.
Use one of the available attributes in the Okta profile.
To direct sign-ins from devices and IPs to Microsoft Entra ID, set up the policy seen in following image. In this example, the Division attribute is unused on all Okta profiles. It's a good choice for IDP routing.
Record the redirect URI to add it to the application registration.
On the application registration, on the left menu, select Authentication.
Select Add a platform
Select Web.
Add the redirect URI you recorded in the IDP in Okta.
Select Access tokens and ID tokens.
In the admin console, select Directory.
Select People.
Select a test user to edit the profile.
In the profile, add ToAzureAD. See the following image.
Select Save.
Sign in to the Microsoft 356 portal as the modified user. If your user isn't in the managed authentication pilot, your action enters a loop. To exit the loop, add the user to the managed authentication experience.
Test Okta app access on pilot members
After you configure the Okta app in Microsoft Entra ID and configure the IDP in the Okta portal, assign the application to users.
In the Microsoft Entra admin center, browse to Identity > Applications > Enterprise applications.
Select the app registration you created.
Go to Users and groups.
Add the group that correlates with the managed authentication pilot.
Note
You can add users and groups from the Enterprise applications page. You can't add users from the App registrations menu.
Wait about 15 minutes.
Sign in as a managed authentication pilot user.
Go to My Apps.
To return to the Okta home page, select the Okta Application Access tile.
Test managed authentication on pilot members
After you configure the Okta reverse-federation app, ask users to conduct testing on the managed authentication experience. We recommend you configure company branding to help users recognize the tenant.
Learn more: Configure your company branding.
Important
Before you defederate the domains from Okta, identify needed Conditional Access policies. You can secure your environment before cut-off. See, Tutorial: Migrate Okta sign-on policies to Microsoft Entra Conditional Access.
Defederate Office 365 domains
When your organization is comfortable with the managed authentication experience, you can defederate your domain from Okta. To begin, use the following commands to connect to Microsoft Graph PowerShell. If you don't have the Microsoft Graph PowerShell module, download it by entering Install-Module Microsoft.Graph.
In PowerShell, sign in to Microsoft Entra ID by using a Global Administrator account.
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"To convert the domain, run the following command:
Update-MgDomain -DomainId yourdomain.com -AuthenticationType "Managed"Verify that the domain has been converted to managed by running the command below. The Authentication type should be set to managed.
Get-MgDomain -DomainId yourdomain.com
After you set the domain to managed authentication, you've defederated your Office 365 tenant from Okta while maintaining user access to the Okta home page.
Next steps
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for