Configure Hybrid Join in Azure AD

Now that Okta is federated with your Azure AD, Office 365 domain, and on-premises AD is connected to Okta via the AD Agent, we may begin configuring hybrid join.

There are multiple ways to achieve this configuration. This topic explores the following methods:

  1. Azure AD Connect and Group Policy Objects

  2. Windows Autopilot and Microsoft Intune

  3. Windows Autopilot and other MDMs

About these methods and the resultant join types

With the Windows Autopilot and an MDM combination, the machine will be registered in Azure AD as Azure AD Joined, and not as Hybrid Azure AD Joined. This is because the machine was initially joined through the cloud and Azure AD.

If you want the machine to be registered in Azure AD as Hybrid Azure AD Joined, you also need to set up the Azure AD Connect and GPO method. When both methods are configured, local on-premises GPOs will be applied to the machine account, and with the next Azure AD Connect sync a new entry will appear in Azure AD. At this time you will see two records for the new device in Azure AD - Azure AD Join and Hybrid AD Join. Both are valid.

For the difference between the two join types, see What is an Azure AD joined device? and What is a hybrid Azure AD joined device? (Microsoft Docs).

Start this procedure

Azure AD Connect and Group Policy Objects

With this combination, you can sync local domain machines with your Azure AD instance. The machines synchronized from local AD will appear in Azure AD as Hybrid Azure AD Joined.

This procedure involves the following tasks:

  1. Install Azure AD Connect: Download and install Azure AD Connect on the appropriate server, preferably on a Domain Controller. See Azure AD Connect and Azure AD Connect Health installation roadmap (Microsoft Docs).

    Create or use an existing service account in AD with Enterprise Admin permissions for this service.

  2. Configure Azure AD Connect for Hybrid Join: See Configure Azure AD Connect for Hybrid Join (Microsoft Docs).

    During SCP configuration, set the Authentication Service to the Okta org you’ve federated with your registered Microsoft 365 domain.

  3. Configure the auto-enrollment for a group of devices: Configure Group Policy to allow your local domain devices automatically register through Azure AD Connect as Hybrid Joined machines.

    See Enroll a Windows 10 device automatically using Group Policy (Microsoft Docs).

How local devices join to Azure AD

Once you’ve configured Azure AD Connect and appropriate GPOs, the general flow for connecting local devices looks as follows:

  1. A new local device will attempt an immediate join by using the Service Connection Point (SCP) you set up during Azure AD Connect configuration to find your Azure AD tenant federation information. The device then reaches out to a Security Token Service (STS) server. The authentication attempt will fail and automatically revert to a synchronized join.

  2. Upon failure, the device will update its userCertificate attribute with a certificate from Azure AD.

  3. On its next sync interval, Azure AD Connect sends the computer object to Azure AD with the userCertificate value. The device will appear in Azure AD as joined but not registered. The sync interval may vary depending on your configuration. The default interval is 30 minutes.

  4. Using a scheduled task in Windows from the GPO an Azure AD join is retried.

  5. Since the object now lives in Azure AD as joined, the device is successfully registered upon retrying.

Windows Autopilot and Microsoft Intune

This method will create local domain objects for your Azure AD devices upon registration with Azure AD. With this combination, machines synchronized from Azure AD will appear in Azure AD as Azure AD Joined, in addition to being created in the local on-prem AD domain.

This procedure involves the following tasks:

  1. Set up Windows Autopilot and Microsoft Intune in Azure AD: See Deploy hybrid Azure AD-joined devices by using Intune and Windows Autopilot (Microsoft Docs).

    The installer for Intune Connector must be downloaded using the Microsoft Edge browser. Since Microsoft Server 2016 doesn't support the Edge browser, you can use a Windows 10 client with Edge to download the installer and copy it to the appropriate server.

  2. Assign licenses to the appropriate users in the Azure portal: See Assign or remove licenses in Azure (Microsoft Docs). License assignment should include at least Enterprise and Mobility + Security (Intune) and Office 365 licensing.

  3. Test the configuration: Once the Windows Autopilot and Microsoft Intune setup is complete, test the configuration using the following steps:

    1. Ensure the device can resolve the local domain (DNS), but is not joined to it as a member. The new device will be joined to Azure AD from the Windows Autopilot Out-of-Box-Experience (OOBE).

    2. On the Sign in with Microsoft window, enter your username federated with your Azure account. You will be redirected to Okta for sign on.

    3. Once the sign-on process is complete, the computer will begin the device set-up through Windows Autopilot OOBE. This may take several minutes.

    4. During this period the client will be registered on the local domain through the Domain Join Profile created as part of setting up Microsoft Intune and Windows Autopilot. A machine account will be created in the specified Organizational Unit (OU). The client machine will also be added as a device to Azure AD and registered with Intune MDM.

Windows Autopilot and other MDMs

If you’re using VMware Workspace ONE or Airwatch with Windows Autopilot, see Enrolling Windows 10 Devices Using Azure AD: Workspace ONE UEM Operational Tutorial (VMware Docs).

If you’re using other MDMs, follow their instructions.

Next steps

Hybrid Azure AD Join integration FAQs

Related topics

Devices