Okta support for hybrid Azure AD joined devices

This topic explains settings and options available in Okta to minimize the use of legacy authentication for registered and new hybrid Azure AD joined devices.

About hybrid Azure AD joined devices

Hybrid Azure AD joined devices are devices that are joined to on-premises Active Directory and registered with Azure AD. These devices allow you to take advantage of both on-premises Active Directory and Azure Active Directory capabilities. With hybrid Azure AD join, you can centrally manage workplace devices that are joined to your on-premises Active Directory while your users can sign into their registered devices using Azure Active Directory.

How to hybrid join devices

To join an AD-joined device to Azure AD, you need to set up Azure AD Connect for hybrid Azure AD join. Additionally, you also need to create a GPO that auto-enrolls AD-joined devices in Azure AD.

When an AD-joined device attempts to join Azure AD, it uses the Service Connection Point (SCP) you configured in Azure AD Connect to find out your Azure AD tenant federation information. It attempts to hybrid join but fails because the userCertificate attribute of the computer object is not yet synced with Azure AD. However, upon failure, the attribute is updated on the device with a certificate from Azure AD. Azure AD Connect syncs this attribute to Azure AD in its next sync interval. Next time when a scheduled task in the GPO retries to hybrid join the device, the task is successful and the device is joined in Azure AD.

This process may take several hours. If you encounter problems during the process, see Troubleshooting hybrid Azure Active Directory joined devices (Microsoft docs).

How Okta works with hybrid Azure AD joined devices

Once your devices are hybrid Azure AD joined, you can use Okta as an Identity Provider (IdP) to secure enrollment and sign on processes on these devices. Okta verifies the user's identity information, and then allows them to register their device in Azure AD or grants them access to their Office 365 resources. The user authenticates with Okta before they can sign into Microsoft Office 365 and other Azure AD resources.

Minimize legacy authentication with Okta

Hybrid Azure AD joined devices running Windows 10 use the WINLOGON service, which uses legacy authentication. MFA can't be enforced on legacy authentication requests, making it susceptible to cyber attacks such as password spray. Therefore, minimizing the use of legacy authentication is a crucial part of securing your environment. Okta offers several solutions to minimize the use of legacy authentication for Hybrid Azure AD joined devices. You can use the following settings available in the Office 365 app sign-on policies to fortify Hybrid Azure AD joined devices.

For registered devices

For devices that are already registered in Azure AD, you can secure the sign-on process by using the Office 365 sign-on policy in Okta. You can modify the policy to restrict access as follows:

1. Allow only select user agent strings to use legacy authentication

You can filter specific trusted clients using the Office 365 app sign-on rules to allow them access to Office 365 resources, for example Windows-AzureAD-Authentication-Provider. It gives you a finer control over user agents that can access the Office 365 apps. See Allow or deny custom clients in Office 365 sign-on policy.

2a. Allow legacy authentication only within local intranet

In your Microsoft tenant, disable all Microsoft services that use legacy authentication. Then, in Okta, modify the Office 365 app sign-on policy to allow legacy authentication only when the device is in the local intranet. See the following:

2b. Require MFA while outside local intranet

If a user is using a device that is not on your local intranet, require them to successfully complete an MFA prompt before granting them access to Azure AD resources. In Azure AD, create a Conditional Access Policy that requires MFA for such users, and then in Okta, modify your Office 365 app setting to use Okta MFA to satisfy Azure AD MFA.

In this scenario, Azure AD redirects the user to Okta to complete the MFA prompt. Upon successful completion of the prompt, Okta passes the MFA claim to Azure AD, and then Azure AD allows the user to access the Microsoft resources. This streamlines the sign-in experience for the user as they have to complete only one MFA prompt. See Use Okta MFA for Azure Active Directory.

We recommend using a combination of Conditional Access Policy and Office 365 app sign-on policy to ensure wide security coverage. Okta enforces its sign-on policy at each sign-on event. After sign-on, Azure AD enforces its Conditional Access Policy at a regular interval to ensure that the access is secure.

3. Block legacy authentication on the Microsoft side

Create authentication policies in Microsoft to block legacy authentication for all Microsoft services. Assign these policies to users. See Disable Basic authentication in Exchange Online (Microsoft docs).

For enrolling new devices

For devices that are not yet enrolled in Azure AD, you can use Okta MFA to add an extra security layer to the enrollment process as follows:

Require MFA while enrolling in Windows Hello for Business

If your users are enrolling a new device in Azure AD, you can require them to complete a step-up MFA prompt in Okta. Upon successful completion of the prompt, Okta passes the MFA claim to Azure AD, and Azure AD allows the user to enroll their device in Windows Hello for Business. The user can then use Windows Hello for Business as a factor to satisfy Azure AD MFA. See Use Okta MFA for Azure Active Directory.

Related topics