Tutorial: Migrate Okta sign-on policies to Azure Active Directory Conditional Access
In this tutorial, you'll learn how your organization can migrate from global or application-level sign-on policies in Okta to Azure Active Directory (Azure AD) Conditional Access policies to secure user access in Azure AD and connected applications.
This tutorial assumes you have an Office 365 tenant federated to Okta for sign-in and multifactor authentication (MFA). You should also have Azure AD Connect server or Azure AD Connect cloud provisioning agents configured for user provisioning to Azure AD.
Prerequisites
When you switch from Okta sign-on to Conditional Access, it's important to understand licensing requirements. Conditional Access requires users to have an Azure AD Premium P1 license assigned before registration for Azure AD Multi-Factor Authentication.
Before you do any of the steps for hybrid Azure AD join, you'll need an enterprise administrator credential in the on-premises forest to configure the service connection point (SCP) record.
Catalog current Okta sign-on policies
To complete a successful transition to Conditional Access, evaluate the existing Okta sign-on policies to determine use cases and requirements that will be transitioned to Azure AD.
Check the global sign-on policies by going to Security > Authentication > Sign On.
In this example, the global sign-on policy enforces MFA on all sessions outside of our configured network zones.
Go to Applications and check the application-level sign-on policies. Select Applications from the submenu, and then select your Office 365 connected instance from the Active apps list.
Select Sign On and scroll to the bottom of the page.
In the following example, the Office 365 application sign-on policy has four separate rules:
Enforce MFA for Mobile Sessions: Requires MFA from every modern authentication or browser session on iOS or Android.
Allow Trusted Windows Devices: Prevents your trusted Okta devices from being prompted for more verification or factors.
Require MFA from Untrusted Windows Devices: Requires MFA from every modern authentication or browser session on untrusted Windows devices.
Block Legacy Authentication: Prevents any legacy authentication clients from connecting to the service.
Configure condition prerequisites
Conditional Access policies can be configured to match Okta's conditions for most scenarios without more configuration.
In some scenarios, you might need more setup before you configure the Conditional Access policies. The two known scenarios at the time of writing this article are:
Okta network locations to named locations in Azure AD: Follow the instructions in Using the location condition in a Conditional Access policy to configure named locations in Azure AD.
Okta device trust to device-based CA: Conditional Access offers two possible options when you evaluate a user's device:
- Use hybrid Azure AD join, which is a feature enabled within the Azure AD Connect server that synchronizes Windows current devices, such as Windows 10, Windows Server 2016, and Windows Server 2019, to Azure AD.
- Enroll the device in Endpoint Manager and assign a compliance policy.
Hybrid Azure AD join configuration
To enable hybrid Azure AD join on your Azure AD Connect server, run the configuration wizard. You'll need to take steps post-configuration to automatically enroll devices.
Note
Hybrid Azure AD join isn't supported with the Azure AD Connect cloud provisioning agents.
To enable hybrid Azure AD join, follow these instructions.
On the SCP configuration page, select the Authentication Service dropdown. Choose your Okta federation provider URL and select Add. Enter your on-premises enterprise administrator credentials and then select Next.
If you've blocked legacy authentication on Windows clients in either the global or app-level sign-on policy, make a rule to allow the hybrid Azure AD join process to finish.
Allow the entire legacy authentication stack through for all Windows clients. You can also contact Okta support to enable its custom client string on your existing app policies.
Configure device compliance
Hybrid Azure AD join is a direct replacement for Okta device trust on Windows. Conditional Access policies can also look at device compliance for devices that have fully enrolled in Endpoint Manager:
- Compliance overview: Refer to device compliance policies in Intune.
- Device compliance: Create policies in Intune.
- Windows enrollment: If you've opted to deploy hybrid Azure AD join, you can deploy another group policy to complete the auto-enrollment process of these devices in Intune.
- iOS/iPadOS enrollment: Before you enroll an iOS device, you must make more configurations in the Endpoint Management console.
- Android enrollment: Before you enroll an Android device, you must make more configurations in the Endpoint Management console.
Configure Azure AD Multi-Factor Authentication tenant settings
Before you convert to Conditional Access, confirm the base Azure AD Multi-Factor Authentication tenant settings for your organization.
Go to the Azure portal and sign in with a global administrator account.
Select Azure Active Directory > Users > Multi-Factor Authentication to go to the legacy Azure AD Multi-Factor Authentication portal.
You can also use the legacy link to the Azure AD Multi-Factor Authentication portal.
On the legacy multi-factor authentication menu, change the status menu through Enabled and Enforced to confirm you have no users enabled for legacy MFA. If your tenant has users in the following views, you must disable them in the legacy menu. Only then will Conditional Access policies take effect on their account.
The Enforced field should also be empty.
Select the Service settings option. Change the App passwords selection to Do not allow users to create app passwords to sign in to non-browser apps.
Ensure the Skip multi-factor authentication for requests from federated users on my intranet and Allow users to remember multi-factor authentication on devices they trust (between one to 365 days) checkboxes are cleared, and then select Save.
Configure Conditional Access policies
After you've configured the prerequisites and established the base settings, it's time to build the first Conditional Access policy.
To configure Conditional Access policies in Azure AD, go to the Azure portal. On Manage Azure Active Directory, select View.
Configure Conditional Access policies by following best practices for deploying and designing Conditional Access.
To mimic the global sign-on MFA policy from Okta, create a policy.
Create a device trust-based Conditional Access rule.
This policy as any other in this tutorial can be targeted to a specific application, a test group of users, or both.
After you've configured the location-based policy and device trust policy, it's time to configure the equivalent block legacy authentication policy.
With these three Conditional Access policies, the original Okta sign-on policies experience has been replicated in Azure AD. Next steps involve enrolling the user via Azure AD Multi-Factor Authentication and testing the policies.
Enroll pilot members in Azure AD Multi-Factor Authentication
After you configure the Conditional Access policies, users must register for Azure AD Multi-Factor Authentication methods. Users can be required to register through several different methods.
For individual registration, direct users to the Microsoft Sign-in pane to manually enter the registration information.
Users can go to the Microsoft Security info page to enter information or manage the form of MFA registration.
See this guide to fully understand the MFA registration process.
Go to the Microsoft Sign-in pane. After you sign in with Okta MFA, you're instructed to register for MFA with Azure AD.
Note
If registration already happened in the past for a user, they're taken to the My Security information page after they satisfy the MFA prompt. See the user documentation for MFA enrollment.
Enable Conditional Access policies
To roll out testing, change the policies created in the earlier examples to Enabled test user login.
On the next Office 365 Sign-In pane, the test user John Smith is prompted to sign in with Okta MFA and Azure AD Multi-Factor Authentication.
Complete the MFA verification through Okta.
After the user completes the Okta MFA prompt, the user is prompted for Conditional Access. Ensure that the policies were configured appropriately and are within conditions to be triggered for MFA.
Cut over from sign-on to Conditional Access policies
After you conduct thorough testing on the pilot members to ensure that Conditional Access is in effect as expected, the remaining organization members can be added to Conditional Access policies after registration has been completed.
To avoid double-prompting between Azure AD Multi-Factor Authentication and Okta MFA, opt out from Okta MFA by modifying sign-on policies.
The final migration step to Conditional Access can be done in a staged or cut-over fashion.
Go to the Okta admin console, select Security > Authentication, and then go to Sign-on Policy.
Note
Set global policies to Inactive only if all applications from Okta are protected by their own application sign-on policies.
Set the Enforce MFA policy to Inactive. You can also assign the policy to a new group that doesn't include the Azure AD users.
On the application-level sign-on policy pane, update the policies to Inactive by selecting the Disable Rule option. You can also assign the policy to a new group that doesn't include the Azure AD users.
Ensure there's at least one application-level sign-on policy that's enabled for the application that allows access without MFA.
After you disable the Okta sign-on policies or exclude the migrated Azure AD users from the enforcement groups, users are prompted only for Conditional Access the next time they sign in.
Next steps
For more information about migrating from Okta to Azure AD, see:
Feedback
Submit and view feedback for