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:
- 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.
- 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.
- Access to Windows Store for Business using AD account. Users can choose from an inventory of applications pre-selected by the organization.
- Microsoft Passport for Work and Windows Hello for secure and convenient access to work resources.
- 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:
(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:
- Object GUID of computer object on-prem.
- SID (Security Identifier) of computer object on-prem.
- 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:
- 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.
- 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.
- 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)
Devices, Security and Identity in #Microsoft365 by Jairo Cadena 
What apps support the SSO experience? Does the web SSO experience only work with IE and Edge?
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
Pingback: More Azure AD and Windows 10 goodness: Enterprise State Roaming public preview! | Active Directory Team Blog
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.
LikeLike
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!
LikeLike
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
LikeLike
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.
LikeLike
In 3b you mention an inherent delay. Are we talking minutes or hours? Thank you for this wealth of information!
LikeLike
The sync’ of the credential written by the computer in its own computer object up to the cloud in the form of a device object, happens every time AAD Connect runs a sync’ cycle. This means that the delay will be up to about the frequency the AAD Connect task runs to synchronize data. This is 3 hours in the AAD Connect update of December 2015. This value cannot be changed. Keep an eye on a future AAD Connect update where we provide additional functionality in this respect.
LikeLike
This value has now been updated with the January build to be 30 minutes.
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/
LikeLiked by 1 person
Are there events, logs, or queries to troubleshoot this setup? No test lab deployments I’ve tried are showing this new SSO experience.
LikeLike
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.
LikeLike
How does this apply to Windows 10 Mobile? Do they get the same benefits?
LikeLike
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.
LikeLike
Pingback: Microsoft Enterprise State roaming – public preview | End User Computing, User Environment Management, Mobility & Monitoring
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.
LikeLike
Pingback: Azure AD and Microsoft Passport for Work in Windows 10 | [Azure] Active Directory by Jairo Cadena
Do we also need to sync the w10 computers to azure with ad connect for this can work?
LikeLike
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.
LikeLike
Do we also need to sync w10 computers with ad connect to azure?
LikeLike
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.
LikeLike
Do we need to sync the windows 10 computers to Azure with AD Connect?
LikeLike
Hi TVH, please see my response to Phil and Prabhat just before this one which addresses the same question.
LikeLike
Do we need to sync the windows 10 computers with AD Connect to Azure?
LikeLike
Hi Trekveer, please see my response to Phil and Prabhat above which addresses the same question.
LikeLike
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
LikeLike
Hi Trekveer, automatic MDM enrollment occurs during Azure AD Join and Add Work or School Account. Domain Join on the other hand doesn’t make use of this functionality as typically domain joined devices are managed by SCCM or Group Policy or other on-premises management system. For more information on the three ways to setup Windows 10 devices for work see my initial post at: https://jairocadena.com/2016/01/18/setting-up-windows-10-devices-for-work-domain-join-azure-ad-join-and-add-work-or-school-account/.
LikeLike
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!
LikeLike
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.
LikeLike
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 🙂
LikeLike
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.
LikeLike
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”}
LikeLike
@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
LikeLiked by 1 person
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 🙂
LikeLiked by 1 person
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
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
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?
LikeLike
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?
LikeLike
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.
LikeLike
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.
LikeLike
Is this a Azure AD Premium function of if we have Office 365 E3 is this also possible?
LikeLike
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.
LikeLike
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?
LikeLike
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
LikeLike
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
LikeLike
I also have the same issue as Mark and Moses. Did you guys find a resolution?
LikeLike
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.
LikeLike
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
LikeLike
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!
LikeLike
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?
LikeLike
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.
LikeLike
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
LikeLike
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.
LikeLike
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?
LikeLike
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
LikeLike
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!
LikeLiked by 1 person
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
LikeLike
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?
LikeLike
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.
LikeLike
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
LikeLike
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
LikeLike
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.
LikeLike
Pingback: Claim rules for the Azure Active Directory (#AzureAD) Relying Party (RP) trust | Yet another identity management blog
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.
LikeLike
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.
LikeLike
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
LikeLike
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.
LikeLike
Hi Jairo!
How does a device determine if Azure AD SSO configuration is federated or not?
Regards Mikael
LikeLike
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.
LikeLike
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
LikeLike
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).
LikeLike
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
LikeLiked by 1 person
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
LikeLiked by 1 person
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
LikeLike
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?
LikeLike
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
LikeLiked by 1 person
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
LikeLike
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
LikeLike
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
LikeLike
Mikael, yes, this is a change we made for Anniversary Update. Now the devices register by default when the SCP and AD FS rules are in place. The GP still can be used to control roll out. Please see the section ‘Deployment and roll-out’ in the following article which is an update to the auto-registration articles that were up to this point: https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-automatic-device-registration-setup/. Please note that will direct all other auto-registration articles (Win7/8.1 and Win10) to this new one.
LikeLike
Pingback: More Azure AD and Windows 10 goodness: Enterprise State Roaming public preview! – Active Directory Team Blog
Can you have multiple Service Connection Points towards one domain? If one domain is synchronized to multiple Azure AD Tenants.
LikeLike
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.
LikeLike
Pingback: Windows Store User Experience in the Enterprise in Windows 10 – Insentra
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.
LikeLike
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
LikeLike
Hi there,
Can App-V be used with a Azure AD joined computer?
Thanks,
Owen
LikeLike
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
LikeLike
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 🙂
LikeLike
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.
LikeLike
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.
LikeLike
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
LikeLike
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.
LikeLike
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.
LikeLike
Pingback: How SSO works in Windows 10 devices | [Azure] Active Directory by Jairo Cadena
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
LikeLike
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!
Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!
Pingback: Evaluation de Enterprise Mobility + Security. Quatrième partie : l’expérience utilisateur SSO avec AZURE AD Join | Antoine DENTAN
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!
LikeLike
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.
LikeLike