Windows 10 Join Method Overview

2020-08-12

In the past on Windows, you had 2 options: Domain join or Workgroup.
Windows 10 add more options which can be done together and some other not.
We’re going to detail, what are each options, there is plenty of article and documentation on how to achieve each of them.
We’re also excluding the consumer option which is Microsoft Account join which is more or less an Azure AD join machine except that it use a Microsoft Consumer account and endpoints.

Provisioning

As we are going see, there is multiple provisioning method to join machines to Active Directory or Azure AD.
The end result in both cases is the same so machines are identical no matter which joining method is used. E.g: an Offline joined and an Online joined machines are identical, it’s just a different joining process.

Active Directory

Active Directory is more than 20 years old (previewed in 1999) even with that age, it is, still, the most used directory service to join Windows Machines and manage them with GPOs or now CSPs.

Online Domain Join

This is the usual “Domain Join” that everybody does when joining a machine to a domain, it requires admin right on the local machine and on the domain.

Sequence

  1. Admin enter the username and password allowing domain join.
  2. Communication between the domain controller and the machine
  3. Reboot
  4. User can logon with a domain account.

Fun fact: Standard users by default can join up to 5 machines themselves to Active Directory (can be changed).

Offline Domain Join

Introduced with Windows Server 2008R2 and Windows 7, Offline domain join allow a machine to join the domain without the need to be on the network.

Sequence

There is 2 way to execute this sequence. The first one is manually running the commands. The second one is using Autopilot and do the domain join over the air but this requires a MDM server.

  1. Administrator/Autopilot generate a text file which contains a base64 blob with djoin /provision
  2. Copy the text file onto the machine
  3. Run djoin /requestODJ
  4. Reboot

For the user first logon, the machine needs to have a line of sight with a domain controller, this can be on the corp network or via VPN. For VPN, you need to have a VPN capable to be triggered at the user logon interface also called GINA sometimes (historic reason it was the name of the DLL in Windows XP doing the user logon, now replaced with the Windows Credential Provider since Vista).
After the first user logon, credentials are cached and a traditional user VPN can be used.

Djoin Command Line Reference: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/ff793312(v=ws.11)

Azure AD

When Microsoft started to create the cloud as we know now, it was mainly an online offering for communication product also known as BPOS (Business Productivity Online Suite), (there’s more history before but archaeology is not the purpose of this post ;), now known as Office 365, this was relying on some back end to sync up users with DirSync, now known as Azure AD Sync, then in 2012/2013 came Azure AD as we know now.

Azure AD Registered

Registration is a form of being part of Azure AD without impacting the machine side.
Works on different type of devices: Windows 10 (any edition Home included), iOS Android and MacOS.

The machine can be domain joined, workgroup or consumer joined, so the user logon aspect does not change however for any authentication to the corporate Azure AD the registration will be used.

Finally, a MAM or a MDM configuration can comes down, if necessary, to protect corporate data.

Sequence

  • Windows
    1. User goes in Settings > Accounts > Access work or school
    2. Click Connect
    3. Login
    4. Machine is registered

Side note: This is what is used for the compliance API integration in Workspace ONE UEM. More info: https://digitalworkspace.one/2020/05/12/compliance-api-msft/

Azure AD Join

For an end-user, there is not much difference between an Azure AD joined machine from a domain joined machine on a day to day basis, that said, everything in the back end change and the behaviour with it too.

As Azure is based in the cloud, there is no issue for joining it over-the-air (OTA) a part of having a network connection. It can be attached to an automatic MDM integration, so device get managed as soon as the device is joined, this feature requires Azure AD Premium. One cool thing is that no reboot is required for this process.

There is 2 provisioning methods to join Azure AD. The most common and largely advertised is the OOBE way, Autopilot can be added on top to make some config before user sign-in.

OOBE

OOBE stand for Out-of-box experience (pronounced oo-bee), it’s the first process that an end-user go through when the machine is started for the first time, hence the name. The user enter an email address and, depending on it, will do an azure AD join for an Azure AD domain or consumer join for a Microsoft account.

OOBE – “Sign in with Microsoft” step
OOBE with Autopilot – “Sign in with Microsoft” step
Sequence
  1. Machine boots
  2. Network connection – required for Azure AD join
  3. Optional: In Autopilot case some configuration is done
  4. User enter it’s UPN (sometimes different from the email address)
  5. Authentication
    1. On Azure AD for managed domain
    2. On the IDP for federated domain
  6. Machine is joined to Azure AD
  7. Optional: MDM enrolment and configuration/applications
  8. User Auto logon

Settings

A workgroup machine can also be Azure AD joined via the Settings > Accounts > Access work or school

Settings – Join Azure AD
Sequence
  1. User enter it’s UPN (sometimes different from the email address)
  2. Authentication
    1. On Azure AD for managed domain
    2. On the IDP for federated domain
  3. Windows ask for confirmation
  4. Optional: MDM enrolment and configuration/applications
  5. Machine is Azure AD joined.
  6. User switch to the new user.

Hybrid Join

As said earlier, Active Directory remains the main directory to join Windows machines.
However, companies adopt more and more cloud apps especially Office 365 and want to start enjoying the capabilities of the cloud, like compliance, conditional access, etc.
But they tend to have large estate so doing a migration over to an Azure AD machine is a big step that a lot are not ready to make for a lot of different reasons.

Hybrid Join answer this desire by allowing a machine to be domain joined and Azure AD joined.

Note: Domain joined machine can be registered in Azure AD and this bring confusion also before 1803 with KB4489894, you had to remove the registered state before trying to join.
More information: https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state

Prerequisites

Sequence

There is 2 way to execute point 1. The first one is traditional estate then do the automatic join. The second one is using Offline domain join with Autopilot and then Azure AD join.

  1. Machine is domain joined: Online, Offline or Offline with Autopilot
  2. Discovery of the Azure AD domain via the SCP object
  3. Machine reach Azure AD
  4. Authentication
    • Password Hash for Managed
    • Windows Integrated Authentication for federated
  5. Machine is Hybrid Joined

Validation

Nothing is really visible from the interface so you can run dsregcmd /status

Hybrid Join – dsregcmd status

Further Reading

There is some great blog out there which go in way more detail on the how each works below some of the best.