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:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin

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 contoso.com 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:

azureADName:contoso.com; 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.

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

  1. Ryan Marchant says:

    What apps support the SSO experience? Does the web SSO experience only work with IE and Edge?

    Like

    • jairoacadena says:

      Ryan, apps that use the Web Account Manager API will support SSO (new in Windows 10). This include Mail/Calendar/People, Office Universal, Office 2016, among others plus any 3rd party that integrates with this API. (I’ll talk more about this in a future post.)

      For browser SSO support, IE and Edge are the supported browsers at this point.

      Like

  2. Ryan Marchant says:

    How is, “Microsoft Passport for Work and Windows Hello” different than Microsoft Passport and Windows Hello without Azure AD Join? I’ve used Passport and Windows Hello with windows 10 and my microsoft account? How is what your suggesting here different?

    Like

    • jairoacadena says:

      With Microsoft Passport for Work the keys are registered with your Azure AD tenant and are associated to the account of the users who provision these keys. After signing in with the gesture (e.g. Windows Hello) the user will enjoy SSO to work resources like Office 365 and some Windows services will run using the work account. For example the user will be able to go the Windows Store for Business, have their OS settings roam across joined devices, etc. As an admin you will be able to manage devices where keys have been provisioned plus you can manage policy like PIN complexity or require TPM for provisioning, etc.

      Microsoft Passport using your Microsoft account will register keys with the Microsoft Account store. Signing in with the corresponding gesture will give the user SSO to Hotmail and others plus access to the Windows Store, Cortana, OS roaming of settings on personal devices, etc. using your Microsoft account.

      I’ll also talk more about this in a future post. Stay tuned.

      Like

  3. Pingback: More Azure AD and Windows 10 goodness: Enterprise State Roaming public preview! | Active Directory Team Blog

  4. Nils van Woensel says:

    Ah I was looking for this feature 5 months ago… Would be an addition to Intune Conditional access! However still Citrix (with srv2012r2) is not able to do DRS registration. Will this be possible in the future?
    And on which Windows 10 build is this possible? I tried this on the 10240 build a few months ago but the GPO policy didn’t trigger any events/traffic to Azure AD.

    Like

    • jairoacadena says:

      Hi Nils, I am glad this aligns with what you were looking for before. This functionality is available in the November 2015 update of Windows 10 which corresponds to build number 10586.

      Windows 10 domain joined devices don’t get enrolled into MDM after registration. These may have other means of management like SCCM or other on-premises solutions.

      For Azure AD Join (work-owned) and Add Work or School Account (personal), device registration happens independently of, and prior to MDM enrollment as two distinct operations, however they occur in a unified manner from the user experience perspective. This unified enrollment experience is possible when the MDM app is configured in Azure AD for a set of users. For Enterprise Mobility Suite organizations, Intune will show in the list of apps under the Applications tab.

      We are also working with leader MDM vendors to integrate with the feature of unified enrollment in Windows 10. Stay tuned!

      Like

    • Andrew Innes says:

      Hi Nils,

      I’m the Authentication Architect for Citrix. It would be great if you can expand on the use case you have in mind for registering with DRS. Are you asking about Citrix session host machines going through AAD domain join, with the desire that the sessions will have SSO to apps that are connected to AAD?

      Thanks.
      Andrew

      Like

      • Nils van Woensel says:

        Hi Andrew,

        Thank you for your response. I see more and more the question from my clients to only allow “Trusted” devices to Exchange Online, SharePoint online etc, but also enable external connected devices. So if you open ADFS to allow modern applications from external (with MFA) this means all devices can connect to the online service like Outlook 2016 Modern Auth for Exchange Online. Now with Intune you can configure Conditional Access. This means that a device needs to be MDM enrolled or Domain joined + Azure DRS joined. For example if you enable Conditional Access for Windows, this means if you want to configure Outlook 2016 Modern Auth in Citrix (2012R2 session host) you get the message “You need to beef up security”. This means enroll in Intune or Domain join + DRS join the server, but that DRS join is not possible with 2012R2. I think the same problem will exist with Citrix (w10) VDI environment if you use non persistant VM. Or else you have an enormous amount of VDI’s registered in Azure DRS.
        In our case this means that we cannot enable Conditional Access for Windows as this will disable access from our Citrix session host with Outlook.
        On ADFS server itself you don’t have enough options in this case to allow/block only trusted devices. I miss the option on ADFS to separate the authentication requests for Exchange Online/SharePoint online. All authentication to ADFS from O365 will come in as Microsoft Online and not all apps support device claims to be able to block them on the WAP proxy.

        Like

  5. brithead4490 says:

    In 3b you mention an inherent delay. Are we talking minutes or hours? Thank you for this wealth of information!

    Like

  6. Cliff says:

    Are there events, logs, or queries to troubleshoot this setup? No test lab deployments I’ve tried are showing this new SSO experience.

    Like

    • jairoacadena says:

      Cliff, I missed this comment from before and I’ve seen based on your comments below that you have gone further on your validation.

      About troubleshooting, the following are some consideration to have:

      1. You can check the current state of the device by running ‘dsregcmd.exe /status’ in a Command Prompt window. You will see two sections, one ‘Device state’ and one ‘User state’. Under the device section check the value of AzureAdJoined which it has to be YES for a registered device. You can also check the tenant information and the domain information where the device is joined to. Under the user section check the value of WamDefaultSet which needs to be YES before you can get SSO. This means that the user in the device authenticated successfully with Azure AD when signing in to the device. You can also check WamDefaultAuthority to show ‘organizations’ and the WamDefaultGUID to show AzureAd in parenthesis.

      2. Logs for registration can be found in Event Viewer under Applications and Services Logs > Microsoft > Windows > User Device Registration. You can enable Analytic and Debug logs before trying registration first. This is done by standing up on the ‘User Device Registration’ node and doing right click > Show analytic and debug logs. Then you need to go to both nodes under it and make sure they are enabled by right clicking on each while standing up on them first.

      3. Retrying auto-registration can be easily done by signing out and signing in back again. You can also launch the task in Task Scheduler.

      4. To see inline verbose logs while registration happens you can run the following on a Command Prompt window:

      psexec.exe -i -s cmd.exe
      dsregcmd.exe /debug

      PsExec is a SysInternals tools that can downloaded from: https://technet.microsoft.com/en-us/sysinternals/psexec.aspx

      5. Once registration succeeds to troubleshoot any SSO issue you can take a look at logs under Applications and Services Logs > Microsoft > Windows > AAD. Follow the same guidance as #1 to enable debug logs.

      Some other considerations:

      1. Make sure the SCP is created successfully in every forest (Configuration Naming Context is per forest and goes to all domains in a forest) where domain joined computers are.
      2. If you are having issues with registration and have AD FS, you should check the issuance transform rules as described in the deployment guide.
      3. If no AD FS, you can check that AAD Connect is sync’ing up the computer as a device in the cloud. You can check whether the computer is in the metaverse of the Sync Service Manager on the AAD Connect server. You can also check that the computer account has the userCertificates populated with the credential written by the computer.

      Like

  7. Tom says:

    How does this apply to Windows 10 Mobile? Do they get the same benefits?

    Like

    • jairoacadena says:

      Tom, Azure AD Join (work-owned devices) and Add Work or School Account (personal devices) are supported in Mobile including phones. So you will be able to join a phone to Azure AD for example without the need of a Microsoft Account (consumer). With this you will have the same benefits like Microsoft Passport for Work, Enterprise Roaming of Settings, cloud SSO, etc.

      On the other hand Domain Join is limited to desktop.

      Like

  8. Pingback: Microsoft Enterprise State roaming – public preview | End User Computing, User Environment Management, Mobility & Monitoring

  9. Matt B says:

    What I would really like is for Azure AD to be a complete replacement for local Active Directory. I know it’s not meant for that right now, but I don’t see any reason why it couldn’t be made to do that if Microsoft chose to.

    Like

  10. Pingback: Azure AD and Microsoft Passport for Work in Windows 10 | [Azure] Active Directory by Jairo Cadena

  11. Prabhat says:

    Do we also need to sync the w10 computers to azure with ad connect for this can work?

    Like

    • jairoacadena says:

      Prabhat, Azure AD connect will automatically take Windows 10 computers and write them up in the form of device objects. There is nothing that you would need to do to enable this behavior.

      Like

  12. Phill Batista says:

    Do we also need to sync w10 computers with ad connect to azure?

    Like

    • jairoacadena says:

      Hi Phil, Azure AD connect will automatically take Windows 10 computers and write them up in the form of device objects. There is nothing that you would need to do to enable this behavior.

      If you have AD FS in your environment and have set the issuance rules appropriately, device objects will be created in Azure AD at the time of registration. Azure AD Connect will then later come and associate the corresponding computer object on-prem with the device object in Azure AD.

      If no AD FS is present, Azure AD Connect will write up the computer objects in the form of device objects in Azure AD with a particular credential that the device registers to the computer object on-prem. It is later when the device completes registration with the credential and obtains the final device certificate. The device object in Azure AD registers this new certificate (its thumbprint) as an identifier of the device.

      Like

  13. TVH says:

    Do we need to sync the windows 10 computers to Azure with AD Connect?

    Like

  14. Do we need to sync the windows 10 computers with AD Connect to Azure?

    Like

  15. We have setup Azure AD + Domain Join + Windows 10 as per article below
    https://blogs.technet.microsoft.com/ad/2016/02/17/azure-ad-domain-join-windows-10/

    We follow article below to configure SCP and ADFS and we have Windows 10 build 10586.164
    https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/

    When running get-msoldevice -all we see

    Enabled : True
    ObjectId : e23c0c16-2b6f-4c4c-b951-2c7c0d74c2d1
    DeviceId : 547ab533-f24c-4ec2-90ba-d86655b19e34
    DisplayName : DESKTOP10
    DeviceObjectVersion : 2
    DeviceOsType : Windows
    DeviceOsVersion : Windows 10
    DeviceTrustType : Domain Joined
    DeviceTrustLevel : Managed
    DevicePhysicalIds : {}
    ApproximateLastLogonTimestamp : 21-3-2016 12:51:00
    AlternativeSecurityIds : {X509:49482A1D1D1CC11611E96FEECB83597A4EC801C0PK8Dw0UM/yD1iRExAqJQhpbD4
    CYTAXGxo6QvdHBSrck=}
    DirSyncEnabled :
    LastDirSyncTime :
    RegisteredOwners :
    GraphDeviceObject : Microsoft.Azure.ActiveDirectory.GraphClient.Device

    In Azure AD we enabled automatic Intune/MDM registration/enrollment as per article below
    https://blogs.technet.microsoft.com/ad/2015/08/14/windows-10-azure-ad-and-microsoft-intune-automatic-mdm-enrollment-powered-by-the-cloud/

    We waited 3+ hours but the device does not show up in Intune.
    Is this even possible i’m getting second thougts 🙂

    Help

    Like

  16. Bryan says:

    Hi Jairo,
    Great article by the way!
    I’m having trouble getting past step 3b (we don’t have ADFS). I’m seeing that the userCertificate attribute on the computer object is populated in the on-prem AD but the device never gets synced to Azure AD. The GPO triggers the task Automatic-Device-Join which runs under SYSTEM without any problem and I have verified that have the SCP is created that you mentioned in step 2. I have verified that the device is not synced by running: Get-MsolDevice -All | %{ if ($_.DeviceTrustType -eq “Domain Joined”) { echo $_ } }
    I have also noticed that there is no certificate generated on the device (no results running the powershell command: dir Cert:\LocalMachine\My\ | where { $_.Issuer -match “CN=MS-Organization-Access” } | fl). I have the latest AD Connect version installed syncing every 30 minutes. Any Ideas where it’s failing? Frustrating to say the least. Thanks!

    Like

    • jairoacadena says:

      Hi Bryan, the steps are 1) Credential is written into AD on-prem; 2) AAD Connect brings the device to the cloud; 3) Device attempts registration with credential in #1 once the device is in the cloud; 4) The device gets the certificate. So it sounds like #1 was completed, and we are stuck somewhere after that. The “Domain Join” attribute is written into the device object only after the device completes registration in #4. You won’t see the certificate until then.

      To check if the device has been written up to the cloud we might want to check for devices but without the “Domain Join” DeviceTrustType filter. This will help know if there is a problem in AAD Connect writing up the device object.

      One more thing that you can take a look is the registration logs in Event Viewer at Application and Services Logs > Microsoft > Windows > User Device Registration. You can stand up on the node and right click to choose View > Show Analytic and Debug Logs. Then go into the two nodes (Admin and Debug) step on them and the right click to enable logs. Kick off the task in Task Scheduler and then get the logs to know why registration failed.

      Feel free to contact me via internal Twitter to exchange emails if you want us to take a look. We can update the discussion for the benefit of the community after that if you want to go that way.

      Like

      • Bryan says:

        Absolutely! We’ll get in touch via email and get back to update the discussion when we have some sort of solution to present. Thanks for your help 🙂

        Like

    • Cliff says:

      I had (have, actually) the same issue and have traced it to some sort of issue with the on-perm computer objects. Deleting the object and rejoining the computer to the domain, allowing the computer object to be recreated, solves the issue. But that obviously inset scalable. I haven’t yet found what within the existing AD objects cause the failure though.

      Like

      • Bryan says:

        Thanks for sharing that Cliff! I was hoping that would help solve my problem so I went on trying that (deleting the computer object and rejoining the computer to the domain) but I’m still facing the exact same issue. I’m getting the following error in the Event Viewer at Application and Services Logs > Microsoft > Windows > User Device Registration > Admin (with event ID 204)
        The get join response operation callback failed with exit code: Unknown HResult Error code: 0x801c0006.
        Activity Id: 9b443e0c-b7e4-46d1-b7b6-ba7ac864d0d6
        The server returned HTTP status: 400
        Server response was: {“ErrorType”:”DirectoryError”,”Message”:”The device object by the given id (6927ff87-8459-47ab-8c0e-9fa38c552ded) is not found.”,”TraceId”:”9b443e0c-b7e4-46d1-b7b6-ba7ac864d0d6″,”Time”:”03-24-2016 17:50:04Z”}

        Like

    • Clark says:

      @Bryan
      Check if you have configured OU filtering in AAD Connect. I believe that the RegisteredDevices container and the OUs containing the computers that you want to register in AAD should be in scope for the sync engine. Need confirm on this though

      Liked by 1 person

      • Bryan says:

        Problem solved! 
        I have OU filtering in AAD Connect enabled and the OU with the Win10 device was not included. When I added that OU and ran a full sync and then ran the Scheduled task “Automatic-Device-Join” on the Win10 computer everything just worked. The device was added to Azure AD and everything else fell into place! Thanks for pointing this out, and a big thanks to Jairo as well 🙂

        Liked by 1 person

  17. Clark says:

    One thing that is not very clear is step 3: “AAD Connect will then later use these attributes in the device object to correlate it with the computer object in on-prem AD”. Based on my test the correlation will occur with an msds-device object created in the RegisteredDevices container, not with the computer object. Can you confirm this observation?
    In other words, for each computer object that gets AAD joined, a, additional correspondent msds-device object is created in AD. … thank you

    Like

    • jairoacadena says:

      Hi Clark, the correlation made by AAD Connect is made between the computer object on-premises and the device object created in Azure AD. When a domain joined device gets registered with Azure AD there is no new device object (msDS-Device) that is created on-premises.

      AAD Connect will use the object GUID and SID that are saved in the device object in the cloud to correlate it with the on-prem computer object. Given that the computer authenticated itself at the time of registration and AD FS rules issuing these attributes as claims are present, the computer could send those same attributes up.

      If you want me to take a look at the observations you are finding feel free to contact me via email and we can look at them together.

      Like

      • Clark says:

        Hello Jairo, I didn’t mention that we have AAD Premium and enabled device writeback. Can you confirm that in case device writeback is enabled, an additional msds-device object will be created in the registereddevices container? that container is where ADFS looks up for device authentication if I’m not mistaken.

        Like

      • jairoacadena says:

        Yes, you are right. If device write-back is enabled a corresponding msDS-Device object should appear on-premises under the RegisteredDevices container.

        Now, we have a bug in our current logic that prevents enabling the scenario of device write back successfully. In this particular scenario there are two legs to consider: 1) the write-up of the computer object on-prem as device object in Azure AD (which enables a correct lifecycle management of the object e.g. if the computer on-prem is disabled then the device object in Azure AD is disabled), and 2) the write-back of the device object in the cloud to a corresponding msDS-Device object on-premises (which is what AD FS would use if device authentication is enabled on-premises).

        After the device object is created by Azure DRS (if you have AD FS or an on-prem STS) if device write-back is enabled, the device object is then written back on-premises. However in the next sync’ cycle of Azure AD Connect, the computer on-premises is associated with the device object in Azure AD and the source of authority for that device object changes from Azure AD to AD on-premises. This is correct from the perspective of the first leg described above (the on-premises computer object being the source of authority for the device object in Azure AD), however the way the current logic goes, is a problem when considering the leg of write-back to the device object on-premises. Once the source-of-authority changes the second leg might have issues. We are currently assessing the impact of this behavior and considering issuing a fix in a future update of Azure AD Connect.

        Thanks for trying out these features. I will be more than happy to keep hearing about what you see while you try them out and deploy them.

        Like

      • Clark says:

        Excellent, thank you for the clarification. Does that mean that the stale device objects will never be cleaned up automatically?
        Lastly, you mentioned that both GUID and SID attributes are used by AADConnect to do the correlation. when I run “get-msoldevice” I can see the GUID, but not the SID. In which attribute do you store the SID? Thanks again, this blog is very useful.

        Like

      • jairoacadena says:

        We are still looking into the issue, but yes, it might mean that the device object on-premises won’t be cleaned up, and in some cases it might not even be created. We hope to have this issue fixed in a soon future update of AAD Connect.

        To your second question, the SID is actually not exposed publically through Graph API (or the cmdlet). It is used internally for matching the corresponding objects. Now, you can see all the attributes that are involved in the sync’ operation including the on-prem SID using the Sync Service Manager in the AAD Connect box.

        Like

  18. Clark says:

    What happens when you have multiple UPN suffixes and only some of them are federated? We have a forest (abc.com) with multiple trees and consequently different UPNs (abc.com, def.com, ghi.com) but the forest root upn (abc.com) is not federated. Which auth path 3/3b do the clients pick? It’s a little confusing as the information is in the configuration partition so I would expect the clients to behave all in the same manner, but which one?

    Like

    • jairoacadena says:

      Clark, the path to go (3b or not) is chosen based on the information similar to what the realm information provides. For example take a look at https://login.microsoftonline.com/common/userrealm?user=@&api-version=2.1 where is your tenant corresponding domain name where computers will register to, and which is the value that must be configured in the SCP in AD on-prem. The attribute “NameSpaceType” will have the value of “Federated” or “Managed” depending on the configuration for that domain name. “Managed” means the computer will use 3b for registration.

      In your case, does the abc.com tree sync’ up to a particular tenant domain name different than the one where the federated trees go?

      Like

  19. Bryan says:

    Hi,
    I’m having some issues with SSO, particular with Office365, with Win10 domain joined devices synced to Azure in the scenario without ADFS. I’m seeing the exact same “problem” that Chris Clark explained in one of his comments (at the very end) in this blog post: https://blogs.technet.microsoft.com/ad/2016/02/17/azure-ad-domain-join-windows-10/

    Quote:
    “…Once joined I have SSO token access to the following. Office 365 Portal, My Apps Portal, Azure RMS Tracking Portal. After about 8 hours the Office 365 portal times out and the portal screen in IE and Edge end up on the login screen saying for security reasons you have been signed out – I login and close/reopen the browser and the login screen says “Connected to Windows” and clicking it does nothing…”
    End of quote
    Did you guys ever get this solved? Or is this by design? I have customers that are running ADFS and we are not seeing this kind of behavior in these cases. It just works without any prompts or timeouts etc. I was expecting the same user experience in the synced Win10 domain joined objects to Azure AD.

    In addition to this I’m also seeing something that I would expect to be working but which is not with Office365 ProPlus Click-To-Run (CTR). When a user starts Word for example the first time after Office 365 CTR is installed (the computer has been rebooted and the user logs in to Windows) the user need to manually sign in (by clicking the sign in link in upper right hand corner) to start getting access to for example OneDrive for Business resources. When the user signs in they are at least not prompted for the password, but at the same time the user needs to initiate the sing-in process manually. This is not the case in customer’s environments where they have ADFS. The first time a user runs an Office365 CTR app they are automatically singed in without any user interaction what so ever.

    Is this something that you are aware of and if so, do you know if and when this be fixed to resemble the ADFS experience? In a smaller pilot it’s ok for us to have the user do this manual step but not when it comes to rolling out Office365 CTR to thousands of clients it will not be a good user experience.

    Like

    • jairoacadena says:

      For the benefit of other readers, Bryan and I have been in contact offline. This is the outcome of that investigation:

      1. About the issue of seeing the message “for security reasons you have been signed out”, this is particular to the Office portal. The reason is, it has set the max age policy for portal admins to 3 hours and for portal users (Information Workers) to 8 hours. In Windows 10 a cookie with the PRT is used to get an access token to the Office portal. After 3 hours (for example for admins) the Office Portal redirects to Azure AD so the user gets a new access token. Azure AD will receive the PRT which is still valid along with a request requiring the user to force authenticate. Azure AD considers this as a conflict as the user has a valid SSO token (PRT) but the app requires the user to authenticate.
      2. About the Office client apps behavior, the reason is basically that Office 2016 client apps are integrating with a new ADAL version that is built on top of the Web Account Manager (WAM or one of the components that implements authentication in Windows 10). This behavior should be vastly improved once Office integrates with the new library.

      Like

  20. filip says:

    Is this a Azure AD Premium function of if we have Office 365 E3 is this also possible?

    Like

    • jairoacadena says:

      Filip, auto-registration of domain joined devices with Azure AD doesn’t require Azure AD Premium.

      Azure AD Premium will give you additional features like Enterprise Roaming of Settings or Device-based Conditional Access.

      Like

  21. Mark Riley (OCG) says:

    I believe that I have followed the steps correctly. I have Device Registration in Azure working properly and the write-back is working without issue. When I attempt to Auto Register a Windows 10 device, I get a 502 Event in the debug log which tells me that RegistrationCertStatus::GetCertificarte failed with error code: 0x80092004
    Previously in the process (also in the debug log) I get a 500 Informational message that CertificateUtil::FindCertificateByOidValue didn’t find any certificate so returning CRYPT_E_NOT_FOUND.

    Any ideas where I should look?

    Like

    • jairoacadena says:

      Hi Mark, why don’t you run the following commands to get more verbose debug information about the registration operation? If you want you can contact me via email with the output and we can take a look together to see where the issue is:

      psexec.exe -i -s cmd.exe
      dsregcmd.exe /debug

      PsExec is a SysInternals tools that can downloaded from: https://technet.microsoft.com/en-us/sysinternals/psexec.aspx

      Like

      • Moses says:

        I’m running into the same error as Mark and am pretty stuck. I have checked the computer object in AD and no certificate is being created and registered under the userCertificates attribute as specified in step (3b) 1.

        dsregcmd.exe /debug gives me the following error:

        GetSimulateSyncJoin: The key was not found, so returning FALSE. Key: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ
        wmain: hr: 0x00000000. Simulating sync join? 0
        DsrDeviceAutoJoin failed 0x8009002d.
        wmain: failed with error code 0x8009002d.
        DSREGCMD_END_STATUS
        AzureAdJoined : NO

        Like

      • Jakster says:

        I also have the same issue as Mark and Moses. Did you guys find a resolution?

        Like

      • jairoacadena says:

        Jakster, Mark, Moses, could you please try something? Can you deregister the device by running in an elevated command prompt window dsregcmd.exe /leave and then reboot again to try registration again? In the past we have had issues where the key that is generated during registration and is associated with the device (to bind the PRT afterwards) had issues (for example due to TPM reset or others). In the next update of Windows (even latest Insider Preview) we changed the process where this key is generated plus added a self-heal logic by checking if this is the case and performing reregistration as appropriate.

        If this doesn’t solve the problem, please send me an email to jairoc at microsoft.com and we can take a look further.

        Like

  22. Rory says:

    Where can we find info on the known limitations of AzureAD-joined workstations/accounts? For example I can’t grant file permissions to an AzureAD user on a joined workstation? I can’t use the UI to add them as a user to sql server, etc. Where can we report these problems?

    e.g. https://social.technet.microsoft.com/Forums/en-US/f2fe50ad-fbc6-4bb7-b67f-ebf17800cdf1/what-is-an-azureadjoined-user-really-and-how-do-i-give-file-permissions-or-anything-else-to-one?forum=win10itprosecurity

    Like

    • jairoacadena says:

      Hi Rory,

      In general terms the following are some limitations of Azure AD joined devices using the November 2015 update when you compare them to what a typical domain joined device can do:

      1. Remote communication to an Azure AD joined device using a work account (AAD account) including remote desktop, WinRM (e.g. remote PowerShell), file sharing, print sharing, etc.
      2. Sign-in to Windows (WinLogon) using certificates (smart card or virtual smart card) not supported.
      3. Printer discovery based on site location.
      4. Granting permissions to resources on an Azure AD joined device including files, folders or services.

      Some of these gaps we will be solving in future updates of Windows.

      If you have other examples that you see important please share them. I’ll work with the writer (TechNet/MSDN type) to have a doc/section where we can document these known gaps and can give the opportunity to users to report others. Thanks for the feedback!

      Like

  23. Rok B says:

    Hi,

    great article, I’ve set up everything as described, my W10 devices get AzureADjoined status, but SSO with O365 apps or portal is still not working (or maybe that I don’t know how it is supposed to work). Should it sing-in without prompts or not?

    Like

    • jairoacadena says:

      Hi Rok, would you mind sending me an email to jairoc at microsoft.com and we can take a look why you are not getting SSO? We can update the discussion for the benefit of the community with any findings afterwards.

      Like

      • Rok B says:

        Hi Jairo,
        the momet I wrote a question (after waiting for a while, double checking everything from GPO to re-creating SPN, to checking client certificate and dsregcmd, I think an hour or so, after workstation joined local domain) I got things working as you described. It was a demo setup for a MS conference, thank “insert-your-favorite” everything worked at the momet of demoing.
        Anyhow I noticed that single sign-on on the O365 portal “timed-out” and after a while (I couldn’t determine the interval, greater than one hour) and I had to sign in “due to securtiy reasons” – I guess it is a built-in security feature of the O365 portal…).
        I am willing to help to improve this “feature”, but this setup was just a demo (on my local hyperv), I will create another one in my demo lab…
        Thank you for your help!

        Best regards,
        Rok B

        Like

      • jairoacadena says:

        I am glad it worked.

        One point that I want to mention about the O365 portal. The reason why you see the “due to security reasons” message is because of the way the Office portal has configured the life time of their cookies. The Office portal has set the max age policy for portal admins to 3 hours and for portal users (Information Workers) to 8 hours. This means that every 3 hours if you are an admin you will be redirected to Azure AD for force authentication. At that point the still valid PRT from Windows will be sent to Azure AD. Azure AD checks that it is still valid but received a force authentication request from the application therefore it will show you the “for security reasons” message and you need to re-authenticate. We are working with the Office portal folks to improve this experience.

        Please keep the feedback coming.

        Like

  24. Michael R says:

    Hey Jairo, thanks for these awesome posts, they have been super helpful. Is Server 2016 required for ADFS to successfully provide SSO for users, such as Rok is attempting?

    Also, is there any way to force detection of Azure AD registration for a user? For instance, I have a Windows 10 device, I had a Domain account and a Microsoft account that used the same email address on that device and it is successfully device registered with AAD.

    I updated the Microsoft account so that it did not conflict with the Domain one and the User State in dsregcmd went from “WamDefaultSet: Yes” (along with the other details), to “NO”. Is there a way to trigger the detection of AAD registration for the user?

    Like

    • jairoacadena says:

      Hi Michael,

      In most cases AD FS of Windows Server 2016 is not needed for SSO. You would need AD FS of WS2016 if you want to do device authentication in AD FS given that Windows 10 uses a different mechanism to authenticate the device that only is supported in AD FS of WS2016.

      About the second point, I would like to learn more about what you are experiencing. In general terms, once the device is registered with Azure AD and you sign in with the work account (your AD account if it is a domain joined device or the AAD account if it is an Azure AD joined device) the WamDefaultSet should be set to YES. If it is not showing that then authentication failed for some reason.

      Feel free to send me an email if you want me to take a look at this behavior.

      Jairo

      Like

      • Michael R says:

        Hi Jairo!

        It turns out running dsregcmd /leave and then starting the task to re-register has fixed up my user issue. It looks like something might have gone a bit funky with my computer object synced into AAD. I did the leave/rejoin and then left it for about an hour (long enough for the AAD AD syncs to complete) and then checked my user status again and it had come right. I am able to sync my user settings via AAD etc now.

        Thanks again man!

        Liked by 1 person

  25. Tedv says:

    Hi Jairo – thanks for the great article.

    I got this working in a test setup but in our production environment we have an issue.

    The computers (and users) are member of a domain SOMETHING.LOCAL. The users have a publically accessible UPN suffix (say SOMETHING.COM) and for them everything works fine with Office 365, ADFS etc. The Office 365 tenant is synchronized and federated with SOMETHING.COM

    When I do the DSREGCMD.EXE /DEBUG as the SYSTEM account I get an AADSTS50107: Requested federation realm object ‘http://SOMETHING.LOCAL/adfs/services/trust/’ does not exist.

    I guess this is because the computer is member of a non public domain.

    I can however add a work account for the user on the domain joined computer with their AzureAD account (user@SOMETHING.COM). After that, single sign on in Edge to for ex portal.office.com works fine and I see the registred device with the user object in Azure AD

    In what way is this functionally different then doing the automatic registration of the domain joined computer to the Azure AD?

    Thanks,
    Ted

    Like

    • Ceth says:

      I have the same problem, although my users are on a domain and subdomain — which are the same internally or externally. I have a hybrid email setup, where all email to the subdomain is handled by Exchange Online, and all other email is handled on premises.

      Every time the machine tries to join to Azure AD, I get event id 304 and 305, which includes the error:

      AdalErrorDesc: AADSTS50107: Requested federation realm object ‘http://my-adfs-farm/adfs/services/trust’ does not exist.

      If you enter the url it is looking for into a browser, it gives HTTP Error 503. The service is unavailable.

      Thoughts?

      Like

    • Ceth says:

      I’m getting the same error as Ted, although the public/private domain is the same. A user can “connect their work or school” account, which gives access to the Windows Business Store (for example), but “AzureAdJoined” and “EnterpriseJoined” both remain “No” when I do a dsregcmd /status.

      Like

    • Fried says:

      Hi Ted,

      I have exactly the same issue than you; obviously the local domain can’t be “seen” by Azure AD.

      Could you find a solution that enables automatic registration of the computer?

      Thanks,
      Friedrich

      Like

    • Fried says:

      Hi Ted,

      I encounter exactly the same issue and the same error message in dsregcmd.exe; could you find a solution for this?

      Obviously, the local domain isn’t trusted by Azure AD, but it seems to work for others… What’s the trick?

      Thanks,
      Fried

      Like

    • jairoacadena says:

      Tedv, in this case where the Active Directory domain name is non-routable or simply different than the validated domain name in Azure AD you will need to make sure that the SCP has information about the validated domain name in Azure AD and that the appropriate rules are present in AD FS to do transformation of the issuerid claim to a value that Azure AD trusts. We have published an updated document for auto-registration of domain joined devices where I explain these rules. See the section about ‘AD FS rules for instant computer registration (federated orgs)’ and notice the issuedid transform claim rule mentioned in that section here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-automatic-device-registration-setup/. Please let me know if that helps.

      Like

  26. Pingback: Claim rules for the Azure Active Directory (#AzureAD) Relying Party (RP) trust | Yet another identity management blog

  27. Patrick says:

    Jairo,
    Is there anyway to allow users to input different credentials rather than SSO authentication with the currently logged in user? I have a scenario where admin logins to O365 are different from the user login to the device. Currently the user is automatically logged in whether they use Private Mode or not. They enter the admin credentials but the logged in user is not the admin user rather the user of the device.

    Like

    • will owen says:

      Patrick, this is due to ADFS doing Integrated Windows Authentication (and hence using current credentials). We use firefox browser to support admin logons for this purpose as its out of the box behaviour is to prompt for creds when hitting ADFS.

      Like

  28. Gideon Kay says:

    Hi Jairo

    Many thanks for this article. Do you have some more concrete troubleshooting pointers. I’m having registration issues despite following to the word your instructions.I’m getting the same errors regarding certificates not found on the local machines. The scp is in place. One machine is giving me a different error trying to register to the wrong tenant (I’m a partner and it a delegated customer) even though that machine is on a totally different windows domain and the registered accounts in the system are the correct ones. Any assistance would be much appreciated as the project is for a school with 500 pupils and roaming tablets

    Many Thanks

    Gideon

    Like

    • jairoacadena says:

      Hey Gideon, if you want send me an email to jairoc at microsoft dot com and we can take a look.

      You can run “dsregcmd.exe /status /debug” on a command line window and see the output. You will see AzureAdJoined value which needs to be YES. If it shows NO then you can try doing manual registration and see the output by running “psexec.exe -i cmd.exe” to open a command line window under SYSTEM context (psexec.exe is a SysInternals tool that you can download from https://technet.microsoft.com/en-us/sysinternals/psexec.aspx). Then you can simply run “dsregcmd.exe /status”. You will be able to see where registration fails. Make sure that the SCP keywords value shows the tenant validated domain name in Azure AD. If the on-prem AD configuration is multi-forest, the SCP will need to be registered in all forests. If AD FS is in the picture make sure that the rules are correct. We have just recently published a new document for auto-registration as we released device-based CA. Take a look at it and see if it helps: ttp://go.microsoft.com/fwlink/?LinkId=823174.

      Like

  29. Mikael says:

    Hi Jairo!
    How does a device determine if Azure AD SSO configuration is federated or not?
    Regards Mikael

    Like

    • jairoacadena says:

      Hi Mikael, upon device registration we take the SCP value and discover the tenant information including the federation server by querying it from Azure AD. This information is cached in the device and used later on during authentication.

      Like

  30. Kieren says:

    Hi Jairo, we have had the Device Auto Registration working fine with Windows 10 (1511). We have Domain Joined devices and using AAD Connect. GPO is set, devices run the scheduled task, usercertificate attribute is created on computer object in AD, get correct information when running dsregcmd /status on the device.
    Now i am testing Windows 10 (1607) and the device registration is not working for these devices. User Device Registration logs show these events

    Event 308 (Warning)
    This Device is joined to Azure AD, however, the user did not sign in with an Azure AD account.
    Event 201 (Error)
    The discovery operation callback failed with exit code: Unknown HResult Error Code 0x801c000c. The server returned HTTP status: 407
    Event 309 (Error)
    Failed to discover the Azure AD DRS service. Exit code Unknown HResult Error code 0x801x0021
    Event 304 (Error)
    Automatic registration failed at join phase.

    I also notice the userCertificate attribute isnt being created on the computer object

    Any ideas? Any other logs or debug i can check?

    thanks

    Like

    • jairoacadena says:

      Hi Kieren, does dsregcmd.exe /status on the 1607 devices show that the device is not registered (AzureAdJoined:NO)? Are these just upgrades from 1511 or brand new? One thing that you can quickly check in one of them is unregistering the device using dsregcmd.exe /leave (on an elevated command prompt window) and then trigger registration again (e.g. sign-out/in).

      Like

      • Kieren says:

        Hi there, we got the 1607 devices registered, it looks like the dsregcmd has changed and now uses HTTPS, so our proxy was blocking traffic to the https path. Once rules were created, devices registered ok.
        NEW PROBLEM – The user state now doesnt complete (running dsregcmd user state is all NO)
        also in the Device Registration event log we are getting (Device is joined to Azure AD, however the user did not sign in with an Azure AD account). We are using AAD Connect so logging in with AD domain account. Once again, works fine in 1511 devices. Any ideas? thanks

        Like

      • Kieren says:

        Sweet, turns out the User State problem was the same. Enabled Analytical and Debug Logs. Checked the AAD logs, which showed more 407 Proxy errors. Configured another HTTPS rule for the path in the logs, and is all working now

        Liked by 1 person

  31. Blue_Cookeh says:

    Hey,

    I’m trying to get our devices sync’d up but am hitting a roadblock with the user portion of this. The device is successfully enrolled but if I look in the Event Viewer I’m seeing authentication errors for the user (error 0xC0000006D) alongside this:

    “OAuth response error: invalid_grant
    Error description: AADSTS50034: To sign into this application the account must be added to the directory.”

    Any ideas? The user I’m logging in as exists in Azure AD with Office365 apps assigned to it and is sync’d from our local AD.

    Thanks

    Like

    • jairoacadena says:

      Is the registration state of the device correct? If you run dsregcmd.exe /status /debug do you see everything in order?

      AzureAdJoined : YES
      WamDefaultSet : YES
      AzureAdPrt : YES (only available in Anniversary Update or recent builds)

      Also can you check that the same user authenticate to Office 365 from a browser session successfully?

      Like

    • Kieren says:

      See above in the forum, resolved it by this – turns out the User State problem was the same type of proxy error. Enabled Analytical and Debug Logs. Checked the AAD logs, which showed more 407 Proxy errors. Configured another HTTPS rule for the path in the logs, and is all working now

      Liked by 1 person

  32. aaronmarks says:

    For anyone receiving the following after a dsregcmd/debug, quadruple check your Claims Rules. I’ve found in multiple cases that the claims rules from earlier installs of ADFS and AAD Connect aren’t compatible with DJ++

    GetSimulateSyncJoin: The key was not found, so returning FALSE. Key: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ

    Like

  33. Kieren says:

    Hi there, we got the 1607 devices registered, it looks like the dsregcmd has changed and now uses HTTPS, so our proxy was blocking traffic to the https path. Once rules were created, devices registered ok.
    NEW PROBLEM – The user state now doesnt complete (running dsregcmd user state is all NO)
    also in the Device Registration event log we are getting (Device is joined to Azure AD, however the user did not sign in with an Azure AD account). We are using AAD Connect so logging in with AD domain account. Once again, works fine in 1511 devices. Any ideas? thanks

    Like

  34. Mikael says:

    Hi Jairo
    We have deployed Windows 10 version 1607(anniversary update) on some off our computers.
    After setup we log on to the computer for the first time and we can se that the task with name Automatic-Device-Join has been triggered and device gets successfully registered in Azure AD. After looking into our deployed GPOs, I can’t find that we have enabled the policy Register domain computers as device or the policy named Automatically workplace join client computers. Even when we look in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin we cant find a reg value. Any suggestions on why devices with Windows 10 version 1607 get registered in Azure AD?
    Kind regards
    Mikael

    Like

  35. Pingback: More Azure AD and Windows 10 goodness: Enterprise State Roaming public preview! – Active Directory Team Blog

  36. Can you have multiple Service Connection Points towards one domain? If one domain is synchronized to multiple Azure AD Tenants.

    Like

  37. Blackforce says:

    Hi Jairo. Great article thanks for sharing. We have got a couple of win10 devices now registered with Azure. When we do a dsregcmd we get the device state up and it says AzureADJoined = Yes. However values like the AzureADMDM Url are empty. Is this normal?

    Also under the User state we only have 3 values. NGCSet = No. Workplace Joined = No and WAMDefaultSet = Error.

    Again is this expected behaviour. Apart from that, in conjunction with Intune conditional access is working ok. Thanks for any help in advance.

    Like

  38. Pingback: Windows Store User Experience in the Enterprise in Windows 10 – Insentra

  39. Jakob Strøm says:

    Hi Jairo.
    I think i have an interesting problem here, that i hope you can answer somehow (Microsft can’t really, even though we have premium support).
    I have set up a local domain, contoso.com. This is Dirsynced/ AD Connect to my Office 365 tenant (NO Azure AD subscription).
    We have bought through CSP the new Windows 10 Enterprise E3 licens for all the users. The information around this product is VERY limited.
    What i can find, is that you should be able to login to your Office365 user on the machine, and then after a reboot be automatically upgraded from pro to enterprise. However this doesn’t happen, even when i have set up device registration. I have confirmed that GPO device registration works, but windows isn’t automatically upgraded.
    If i however non-join the PC from the on-prem AD, and do a azure-ad domain join manually from the PC (apparently this is possible even if you don’t have an AAD subscription), the windows is after reboot instant upgraded to enterprise.
    When this is done, you cannot domain join it to a local on-prem AD, so we can’t give the computer GPO’s and stuff like that.
    If we then remove the AAD domain join from the PC, reboot, log in with local account and domain join the PC to the on-prem AD, the PC is still on the Enterprise edition. How come that is?
    It’s a new product, so there really isn’t much information on this, but my initial thought was that you just add a school account to your local domain joined pc, and you could have enterprise because of your license in the cloud. This is not what we are seeing however. The little information i can find around this license type is that it is user dependant, so if you remove the license from the user in the cloud, it should go back to pro edition. This is not the case but we are afraid that the enterprise license will at some point be downgraded as the user is signed in with a local AD account instead.

    Like

    • jairoacadena says:

      Hi Jakob,

      I am not familiar about the mechanics used in Windows to upgrade the edition (e.g. from Professional to Enterprise). The features described in this article are functional on a Professional edition of Windows 10. Now let me add some additional thoughts.

      If you have Office 365, then you have Azure AD. The Windows 10 Enterprise E3 license include Windows 10 Enterprise + Azure AD Free (https://technet.microsoft.com/en-us/itpro/windows/deploy/windows-10-enterprise-e3-overview).

      With Azure AD Free you can do Azure AD Join or you can do domain join auto-registration with Azure AD but some of the benefits I talk in this post like MDM auto-enrollment, Enterprise Roaming of Settings or device-based conditional access are only available in Azure AD Premium editions (P1 or P2). See the following link to learn what you can do with the different versions of Azure AD: https://www.microsoft.com/en-us/cloud-platform/azure-active-directory-features.

      Now, assuming you have Azure AD Premium, all these benefits are available with Windows 10 Professional. Windows 10 Enterprise will give you additional benefits (many security related) as described in the overview document I share at the beginning of this response. So if licensing expires and your Windows devices are reverted to Professional edition, the benefits described in this article are still functional. If you are relying on other specific features of Windows Enterprise like say, Credential Guard, Device Guard, AppLocker management, App-V, UA-V, etc. then you might need to worry about the downgrade.

      You can add Azure AD Premium (P1 or P2) to your existing Windows 10 Enterprise E3 to get the benefits described at the beginning of this article. You can also evaluate the SPE E3 (Secure Productive Enterprise) which is Win 10 Enterprise E3 + EMS E3 (Enterprise Mobility + Security Suite, including Azure AD Premium, Intune and RMS) + Office 365 E3.

      Jairo

      Like

    • Matt says:

      You’ve probably solved this by now but:
      Roll back to Windows 10 Pro at any time. When a user’s subscription expires or is transferred to another user, the Windows 10 Enterprise device reverts seamlessly to Windows 10 Pro edition (after a grace period of up to 90 days).
      https://technet.microsoft.com/en-us/itpro/windows/deploy/windows-10-enterprise-e3-overview?f=255&MSPPError=-2147217396

      I have similar questions to yourself, reach out to me if we can discuss: matt AT originit.co.nz

      Like

      • Sorry i havent been able to answer this sooner.
        After much headache with Microsoft support, i finally got through to somebody that (in writing), would promise me that it wouldn’t revert back to Pro if the Azure device Registration was still running.
        It has been more than 90 days now, and nothing has happened 🙂 ! So as long as you keep device registration syncing, you can do a local domain join after you have been upgraded.
        This is by no means a decent solution, and i really hope they change things, so that you can be upgraded by simply connecting your MS 365/Azure account to the machine. This way you could be upgraded without having to do an Azure domain join, and the whole process of reinstalling a PC would be much better..
        An ex is that we cannot use SCCM or MDT for deployment because you have to have the manual steps of Azure Domain Join…
        Hope it clears any confusion up for you 🙂

        Like

      • Matt says:

        I was able to have an on-prem AD joined machine, then join AAD (either via GPO or manually via settings > accounts ..) and Win10 E3 would activate to Enterprise once logged in via the users UPN. I never had to un-join on-prem AD to get it to work, it was pretty seamless. I was testing using Win10 Pro Creators Ed.

        Like

  40. Thanks for the wonderful write-ups and they are very helpful! I have few questions on Azure AD connect and ADFS and would appreciate your help.

    Let’s say I have an Azure AD subscription and I currently have Windows 7 machines in my network. I also have Azure AD connect and ADFS servers. What are the possible set of considerations for the following:
    a) When I move all my end machines to Windows 10, how will things change? What are the changes I should be planning for (if any)? And how will authentication from Windows 10 be affected.
    b) If I have only one AD forest being synced to Azure AD as on date and If I have plans to add a new forest with a one way trust to existing forest, what should be my thought process? How will this impact my existing solution.
    Thanks in anticipation.

    Like

  41. Mikael Cavrak says:

    Hi Jairo,

    I hope you are fine. I have question regarding Sign-In to Windows with Windows Hello Credentials in a Hybrid mode with Azure AD.

    What I have done so for is that
    1. Enabled our Windows 10 devices(version1607) that are joined to onpremise AD to automatically join Azure AD. I can see that the device is successfully registered by running the command get-MsolDevice + dsregcmd.exe /status
    2. Received an warning event in User Device Registration event log that says. This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Passport provisioning will not be enabled. User: SID of my User. Made a Initial log on to Windows 10 on my domain-joined machine with my Azure AD UserPrincipalName, which is kind of odd but worked. Should this really Work?
    3. After log in I’m presented with create a work account PIN which good. I completed the PIN creation step.
    4. Signed off Windows and thought that I can do Sign On to Windows with Azure AD UserPrincipalName and PIN, but that options is not there on the Sign On page.

    Is this expected behaviour regarding Windows Hello for Buisness and Domain Joined machine? Please explain?

    Kind regards

    Mikael

    Like

  42. James says:

    With the release of Device Registration for Windows 7 is it possible to achieve SSO without ADFS similar to Windows 10 devices. I noticed that the usercertificate doesn’t populate with the new Windows 7 MSI + SCP/GPO it tries to validate against Azure first but goes into MFA with the URI string and fails. When I tested the long string by copying into a browser with a username and password it kicks on MFA even though we don’t have MFA enabled. Perhaps this isn’t even possible without ADFS on Windows 7. Any help greatly appreciated.

    Like

  43. James says:

    Is it possible to achieve SSO with Windows 7 and Password Sync no ADFS? With testing Windows 7 with the new MSI for device registration with SCP/GPO and no ADFS the auto join process appears to use a string that fails against the Azure AD. When I copy that same string from the event logs into a browser it shows the UPN correctly populated then I put a password in and it goes into MFA which is strange as its not set anywhere in Azure on that account or for device registration. Any help appreciated.

    Like

  44. Pingback: How SSO works in Windows 10 devices | [Azure] Active Directory by Jairo Cadena

  45. Jack Rudlin says:

    Hi Jairo,

    On Win10 1607 on new Dell 7275 devices, run as the SYSTEM account, dsregcmd /debug:

    Automatic device join pre-check tasks completed.TenantInfo::Discover: DsrBeginDiscover failed. 0x80072efd
    wmain TenantInfo::Discover failed with error code 0x801c0021

    Any ideas?

    thanks

    Jack

    Like

  46. Pingback: (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail « Jorge's Quest For Knowledge!

  47. Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!

  48. Pingback: Evaluation de Enterprise Mobility + Security. Quatrième partie : l’expérience utilisateur SSO avec AZURE AD Join | Antoine DENTAN

  49. I am able to get the Windows 10 1607 device joined in AD Successfully, however all user state data is NO – And I get event id 308 “This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Passport provisioning will not be enabled.”

    I’m at a loss on what to troubleshooting next – Windows 7 and 8.1 join fine with the workplacejoin application load; however Windows 10 devices are no Bueno.

    please help!

    Like

  50. Matt says:

    If we are automatically enrolling devices in AAD as per GPO instructions here:
    https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup
    And then enabling bitlocker via script under an admin context (non-InstantGo devices)
    eg https://www.powershellgallery.com/packages/Enable-AADBitlocker/0.0.0.2/DisplayScript

    Then a “user” hasn’t done any of this? I am worried that the device won’t shows in the portal, hence we can’t get the key?

    Further, the FAQ from the link above
    Windows 10 devices that are domain-joined with automatic device registration do not show up under the USER info. You need to use PowerShell to see all devices
    https://docs.microsoft.com/en-us/azure/active-directory/active-directory-device-registration-faq

    So the question is under Auto-enrollment and manual/scripted Bitlocker enablement, how do we see the bitllocker keys in AAD GUI?
    In my scenario I need to perform this on behalf of the users and I don’t know their creds.

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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