How Domain Join is different in Windows 10 with Azure AD

In the previous post I talked about the three ways to set up devices for work with Azure AD. In this post I will talk about Domain Join and how additional capabilities are enabled in Windows 10 when Azure AD is present.

Domain Join until now

Domain Join has been deployed by many of you since the beginning of this millennium (although Domain Join existed even before AD was born and Windows NT was around).

Domain Join adds a computer to a particular realm, the Active Directory domain. The computer gets a unique identity and a channel is created so admins can reach out to the computer for settings and policy purposes (a.k.a. Group Policy).

When the computer is physically in the domain network it authenticates to the domain through a domain controller (DC). The computer participates in authorization decisions when accessing other resources in the domain. Users who sign-in to these computers using their AD accounts get authenticated to the domain as well.

Domain Join in Windows 10 and Azure AD

None of the existing behaviors for Domain Join change in Windows 10, however new capabilities light up when Azure AD is in the picture:

  1. Users don’t see additional authentication prompts when accessing work resources (a.k.a. SSO). Users enjoy SSO to Azure AD apps even when not connected to the domain network.
  2. Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a Microsoft account (e.g. Hotmail) to see settings across devices.
  3. Access to Windows Store for Business using AD account. Users can choose from an inventory of applications pre-selected by the organization.
  4. Microsoft Passport for Work and Windows Hello for secure and convenient access to work resources.
  5. Restriction of access to apps from only devices that meet compliance policy.

Domain joined devices will automatically register to Azure AD and avail of the above mentioned experiences. You can enable this functionality in your organization quite easily through a particular Group Policy. Note that you need to have the latest version of Azure AD Connect (AAD Connect). Look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

To understand how this process works let’s consider the following illustration:

Blog - Windows 10 and Domain Join Registration



(1) Policy signals device to start auto-registration with Azure AD

When the policy Register domain computers as devices is pushed down to the computer via Group Policy the device registration process will trigger. This policy is found at:

Computer Configuration/Policies/Administrative Templates/Windows Components/Device Registration

Please notice that if you are using the Group Policy management console from Windows Server 2012 R2 the policy name is Automatically workplace join client computers and is found at:

Computer Configuration/Policies/Administrative Templates/Windows Components/Workplace Join

The registry key value for this policy in the device is the REG_DWORD value autoWorkplaceJoin under:


A task registered in Task Scheduler with name Automatic-Device-Join under \Microsoft\Windows\Workplace Join triggers once the registry key value for the policy changes. A value of 1 means that auto-registration is enabled.

(2) Device queries Active Directory to get information about Azure AD tenant

The task which runs as SYSTEM reaches out to AD using the computer identity to query Azure AD tenant information stored in a Service Connection Point (SCP) object in the configuration naming context of the forest where the computer domain belongs.

The SCP is created by AAD Connect during Express installation. AAD Connect provides a PowerShell cmdlet to create the object manually. Please see more details at step-by-step to register Windows 10 domain joined devices to Azure AD. This SCP is placed in the following location (for example for the domain):

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com

The keywords multi-valued attribute on this object contains two values, one for the tenant domain name and one for the tenant ID. For example:; azureADId:6c8b4242-a724-440d-a64c-29373788285b

(3) Device authenticates itself to Azure AD via AD FS to get a token for registration

Once it gets this information, it authenticates to Azure DRS via AD FS using Windows Integrated Authentication (i.e. Kerberos auth using the computer identity). AD FS issues a token to Azure AD before Azure AD issues the final token for Azure DRS. Three claims are passed to Azure AD via the AD FS token when the computer authenticates, and are written as attributes in the newly created device object:

  1. Object GUID of computer object on-prem.
  2. SID (Security Identifier) of computer object on-prem.
  3. Claim stating that computer is domain joined.

These claims are generated thanks to three AD FS issuance transform rules that are created by AAD Connect during Express installation. To know how to create these rules manually please see more details at step-by-step to register Windows 10 domain joined devices to Azure AD.

AAD Connect will then later use these attributes in the device object to correlate it with the computer object in on-prem AD. This is needed for lifecycle of the device object which is authoritative on-prem. For more details please look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

(3b) Device authenticates itself to Azure AD (when Azure AD SSO configuration is password hash sync’ i.e. no AD FS)

When Azure AD SSO configuration is not federated but password hashes are sync’ed from on-prem, the following happens for the device to authenticate to Azure DRS:

  1. The task will create a credential in the form of a self-signed certificate and will register with the computer via LDAP in the userCertificates attribute.
  2. AAD Connect detects that the computer has registered this credential and takes it up to Azure AD in the form of a device object holding this credential, the object GUID and the computer SID.
  3. The task will use the credential in #1 to authenticate to Azure DRS directly once the device is created in #2.

Please notice that there is a inherent delay between the time the policy reaches the device and the device is ready for registration. This is because the credential that is used to complete device registration against Azure AD must flow up through AAD Connect in the absence of federation. For more details please look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

(4) Device generates keys used in device registration

The task generates a private/public key pair to be used in a certificate signing request (CSR) to Azure DRS to obtain the certificate that the device will use to authenticate to Azure AD later on.

In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication. This removes the risk of token replay in other devices. The PRT is the token used to provide SSO when users in that device access Azure AD applications. Please look for a future post about SSO in Windows 10 devices to understand in detail how this works.

If AD FS vNext is deployed (i.e. AD FS in Windows Server 2016 which is in Production Preview as of the date of this post), the device will also obtain an AD FS PRT for SSO to AD FS applications. Please look for a future post that I will publish about AD FS support for Windows 10.

If the device has a Trusted Platform Module (TPM) the private keys will be hardware protected.

(5) Device registers with Azure AD via Azure DRS

The task sends the CSR obtaining the certificate which places in the LocalMachine\My store. A device object is created in Azure AD and the certificate thumbprint is associated with it.

In addition the public key for PRT binding is registered with the device object as well. To learn how this key is used during authentication to protect the PRT look for a future post where I’ll cover the topic of SSO in Windows 10 devices.


Final thoughts

Once registration is complete users will enjoy the new experiences described at the beginning of this post. IT will also be able to restrict access to only devices that are domain joined or only domain joined devices that are compliant. Please also look for a future post that I will publish about device conditional access and Windows devices.

Until next time,

Jairo (Twitter: @JairoC_AzureAD)

This entry was posted in AD FS, Azure AD Connect, Azure AD Join, Device Conditional Access, Device Registration, Domain Join, Microsoft Passport for Work, On-premises Active Directory. Bookmark the permalink.

142 Responses to How Domain Join is different in Windows 10 with Azure AD

  1. Ben says:

    Hi Jairo,

    I am not able to get this working and cannot find any information on these error codes anywhere

    dsregcmd::wmain logging initialized.
    DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domainController:\\ isDcAvailable:true }
    PreJoinChecks Complete.
    preCheckResult: Join
    isPrivateKeyFound: undefined
    isJoined: undefined
    isDcAvailable: YES
    isSystem: YES
    keyProvider: undefined
    keyContainer: undefined
    dsrInstance: undefined
    elapsedSeconds: 0
    resultCode: 0x0
    Automatic device join pre-check tasks completed.
    TenantInfo::Discover: Tenant type detection, comparing IDP auth URL and auth code URL.
    IDP auth URL : “”.
    Auth code URL: “”.
    TenantInfo::Discover: IDP auth URL and auth code URL contain the same host. Tenant is managed.
    TenantInfo::Discover: Join Info { TenantType = Managed; AutoJoinEnabled = 1; TenandID = xxxxxxxxx-xxxxxxxxx; TenantName = }
    DsrDeviceAutoJoin failed 0x801c03f2.
    wmain: failed with error code 0x801c03f2.
    AzureAdJoined : NO
    EnterpriseJoined : NO


    • Augusto says:

      I have the same issue. Any updates o feedback?


      • jairoacadena says:

        Augusto, same question I asked Ben to you: is your tenant a non-federated tenant? If so take a look at my response to Ben and see if that applies to you.


    • Ben L says:

      I have not heard anything. Should the tenant name show the


      • jairoacadena says:

        Ben, I see from the output “Tenant is managed”. To confirm, is your configuration non-federated? If so the way the device registers is by relying on Azure AD Connect to sync’ the a credential in the computer account on-prem (a credential that the computer itself writes in the userCertificate attribute of its own computer account) to Azure AD in the form of a device object (holding that credential). After the device is created in Azure AD, the device will reach out to Azure AD for registration using that credential. If this process has not been completed by Azure AD Connect then registration will fail. If this is the case you can take a look at Azure AD Connect sync’ metaverse and see whether you find the computer sync’ing to Azure AD.


      • Ben L says:

        You are correct it is not federated. So if we have filtered our OUs to only sync OUs with user objects than the device won’t ever register? Is that correct? I would need the device OU syncing so that it sees it in the on-premise active directory?


      • jairoacadena says:

        That is correct. The computer account needs to be in scope for sync’ so it gets into Azure AD as a device object with the credential than later can be used to complete registration.


      • Ben L says:

        That was the issue. I was not syncing the OU where the devices were located within Azure AD Connect. I also had to open the synchronization service manager. Click on Connectors and then the on-premise domain to open the connector designer. Under select object types device was unchecked. Once I checked that box and ran a full import and full synchronization it began working completely.

        Thank you for your help!


  2. amit says:

    while running dsregcmd.exe /status then under user state ngcset = No . What it meant and how to resolve it . Any help will be appriciated.


    • Jairo says:

      NgcSet refers to whether the user has provisioned Windows Hello for Business (WHfB). Azure AD joined devices provision WHfB by default when the user signs in for the first time to the device. Hybrid Azure AD joined devices is off by default. There is Group Policy that you can enable, however there is additional configuration needed on-prem to support WHfB authentication to DCs. When the user provisions WHfB, NgcSet must show YES.


  3. Kieren says:

    Hi there. All of our Devices have registered fine, but we are finding the odd users (User State) when running dsregcmd /status showing WamDefaultSet : Error.
    This causes issues with modern apps, like for example Store opens with an error
    Have tried dsregcmd /leave and then re-registered device, tried new user profile. Nothing seems to work.
    Any ideas, thanks


    • Kieren says:

      | User State |

      NgcSet : NO
      WorkplaceJoined : NO
      WamDefaultSet : ERROR
      AzureAdPrt : YES


      • Jack Lewis says:

        We are also having the same issues, did anybody manage to resolve this?


      • Jairo says:

        Jack, see my response to Kieren and see if you can try those steps.


      • Jack Lewis says:

        Hi Jairo,

        Thank you for the swift response.
        The output from a non-elevated command prompt, returns the following:
        NgcSet : NO
        WorkplaceJoined : NO
        WamDefaultSet : NO
        AzureADPrt : NO

        Looking in the event viewer, under the User Device Registration app logs, I’ve managed to find the following:
        Event ID 318:
        This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Password provisioning will not be enabled.




      • Jairo says:

        Kieren, can you run the command with the /debug parameter in a NON elevated command prompt window? Basically run from a command prompt window under the current logged-on user context:

        dsregcmd.exe /status /debug

        To get the value of WamDefaultSet the tools asks the Web Account Manager for the account that has been set as the default in Windows. ERROR would mean that the API call failed. The /debug switch will output the actual error.


      • Lee Sands says:

        Apologies for the hijack but our WamDefaultSet is also at an error state.
        running dsregcmd.exe /status /debug (non-elevated) returned the foloowing error for me:

        get_DefaultWebAccount returned nullptr. Default account is NOT set.

        Any ideas?


      • Jairo says:

        Hi Lee, that suggests that the user didn’t authenticate successfully to Azure AD during sign-in to Windows (assuming AzureAdJoined is YES).

        You can check that the WS-trust usernamemixed end-point is enabled and accessible by the device (used upon sign-in to Windows) (also assuming that the user can authenticate successfully to Office 365 or other Azure AD backed apps from any browser for example).

        I have also seen issues on devices that have been upgraded from 1402 version of Windows where we were registering device state in a slight different manner and special keys provisioned in the TPM wouldn’t work in 1511 and others. You can try resetting the TPM and let the device register again.

        BTW, since 1607 we added a field called AzureAdPrt to the output. Is your version 1511? if 1607 or above you should check better this value instead, although the WamDefaultSet can be used as well to check successful authentication.

        Liked by 1 person

      • Lee Sands says:

        Hi Jairo,

        Thank you for the quick response. In anwser to your questions, we are trying to join our machines to azure ad with no luck.

        WS-trust usernammixed is enabled and we can do everything else 365/Azure wise – users have SSO to Office 365, we can wokplace join users on windows 10 machines, Office 2016 is signed in and successfully links with OneDrive for business and our Machines are “Hybrid Azure AD Joined”

        The machine I am currently using is version 1702 and we dont use TPM at all….

        AzureADPrt states “No”

        The only thing we cannot do is join the machine to Azure AD, we are currently trying to leverage this for our mobility users…..Event logs in “User Device Registration” ultimately give two errors – both Event ID 304 – “A specified authentication package is unknown”.

        Aside from this there are some event logs about accessing the registry but not a lot else.

        We have been banging our heads with this problem for a few weeks now.

        Any ideas would be greatly appreciated


  4. Pablo Banzato says:

    Hi Jairo, i am trying to find the big picture difference in features between “Azure AD Joined” and “Domain Joined” for DeviceTrustType, especifically about the Automatic Bitlocker encryption and subsequent key recorded in the Azure Portal. Can you point me in the right direction to get this information?

    Thank you and best regards.


    • Raj says:

      It is not explained as we are expecting.. you were able to find the difference?


      • Raj says:

        if we see the Azure conditional access settings.. we have an option like “Require domain joined (Hybrid Azure AD)” so both the same ?


      • Jairo says:

        Raj, in the Azure AD conditional access UI, the option that reads “Require domain joined (Hybrid Azure AD)” will permit access to users on devices that are hybrid Azure AD joined but no Azure AD joined. Hybrid Azure AD joined devices are domain joined devices that have been registered with Azure AD and that as they already have a relationship with AD (on-prem) they are already managed by the organization (Group Policy, SCCM or others). Azure AD joined devices require an MDM like Microsoft Intune (part of Enterprise Mobility + Security or EMS) to be marked as ‘Compliant’. For differences between Azure AD joined and hybrid Azure AD joined (and Azure AD registered i.e. BYOD) see this document:


    • Jairo says:

      This document explains the differences between Azure AD joined, hybrid Azure AD joined and Azure AD registered devices: For BitLocker in particular, the key is escrowed to Azure AD automatically on Azure AD joined devices with certain capabilities. Hybrid Azure AD joined devices can escrow the key to Azure AD if the user manually selects so in Windows.


  5. Jan says:

    Hi Jairo,
    Thanks for the really great background info on how all this works behind the scenes.
    The main scenarios discussed are always
    – AD Join and then AAD Join
    – AAD Join only
    However, would it technically be possible to switch the order of the first one around?
    – AAD Join and then AD Join
    My guess is that AAD Connect would struggle to correlate the objects in AD and AAD. Was hoping you might have some thoughts on this.


    • Jairo says:

      Hi Jan, we currently have a hard block in the NetJoin API (the one that does domain join a.k.a. AD join) when the devices is already Azure AD joined. In other words, that path is not technically possible even if you tried. Any thoughts on why would you be interested in this path? I have heard some thoughts but wanted to see if you had any particular insights.


  6. jones1337 says:

    I’m configuring automatic registration of Windows domain-joined devices with Azure Active Directory according to Step 2 is a quite complicated step. However, I see in ADFS on Windows Server 2016 the following is available in the AD FS management console: AD FS > Service > Device Registration

    Here right now it tells me “The Active Directory forest is not configured for device registration with this AD FS farm” and then you can press Configure device registration. Will this actually perform Step 2 for you?


    • Jairo says:


      That option in AD FS 2016 is actually to enable device registration in AD FS itself. This is specifically intended for on-premises only organizations (organizations that don’t have Azure AD) to enable in particular Windows Hello for Business. That option won’t do step #2.

      In terms of the complexity of step #2 we are looking for ways to make it simpler in the next update of Windows (RS4, this spring). Stay tuned!



  7. Al says:

    I wonder, then, is the Microsoft Sign in Assistant install still needed for end user devices? Does it have any function any more?


  8. Pingback: How Domain Join is different in Windows 10 with Azure AD | [Azure] Active Directory by Jairo Cadena – More Stuff 2 Read [Quite Sparsely]

  9. Pingback: #AzureAD device-based conditional access and #Windows 7/8.1 | [Azure] Active Directory by Jairo Cadena

  10. Pingback: Setting up Windows Hello for Business with Intune – Micro-Scott – Blogging Windows and Device Management

  11. Mike says:

    Thanks for the great articles Jairo!
    I wanted to ask you about a situation we are running into using the 3b option above and conditional access.

    AAD usernames are (Alternate ID).
    Devices are
    Devices are showing up in the Azure portal as Hybrid Domain Joined registered.

    Scenario 1:
    When attempts to sign in to the O365 portal on a domain joined PC, they are blocked by conditional access for not having a domain joined PC.
    dsregcmd /status:
    AzureAdJoined: Yes
    KeySignTest: Passed
    WorkplaceJoined: No
    WamDefaultSet: No
    AzureAdPrt: No
    IsUserAzureAD: No

    Scenario 2:
    When attempts to sign in to the O365 portal on a domain joined PC, they are granted access.
    dsregcmd /status:
    AzureAdJoined: Yes
    KeySignTest: Passed
    WorkplaceJoined: No
    WamDefaultSet: Yes
    AzureAdPrt: Yes
    IsUserAzureAD: Yes

    Are Alternate IDs support by Hybrid Domain Join and Conditional Access, or is Scenario 2 the only way it will work?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s