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 
Hi Jairo,
I am not able to get this working and cannot find any information on these error codes anywhere
dsregcmd::wmain logging initialized.
DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domain:company.com forest:company.com domainController:\\DC.company.com isDcAvailable:true }
PreJoinChecks Complete.
preCheckResult: Join
isPrivateKeyFound: undefined
isJoined: undefined
isDcAvailable: YES
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: undefined
elapsedSeconds: 0
resultCode: 0x0
Automatic device join pre-check tasks completed.
TenantInfo::Discover: Tenant type detection, comparing IDP auth URL and auth code URL.
IDP auth URL : “https://login.microsoftonline.com/company.onmicrosoft.com/wsfed”.
Auth code URL: “https://login.microsoftonline.com/company.onmicrosoft.com/oauth2/authorize”.
TenantInfo::Discover: IDP auth URL and auth code URL contain the same host. Tenant is managed.
TenantInfo::Discover: Join Info { TenantType = Managed; AutoJoinEnabled = 1; TenandID = xxxxxxxxx-xxxxxxxxx; TenantName = company.onmicrosoft.com }
DsrDeviceAutoJoin failed 0x801c03f2.
wmain: failed with error code 0x801c03f2.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO
LikeLike
I have the same issue. Any updates o feedback?
LikeLike
Augusto, same question I asked Ben to you: is your tenant a non-federated tenant? If so take a look at my response to Ben and see if that applies to you.
LikeLike
I have not heard anything. Should the tenant name show the onmicrosoft.com?
LikeLike
Ben, I see from the output “Tenant is managed”. To confirm, is your configuration non-federated? If so the way the device registers is by relying on Azure AD Connect to sync’ the a credential in the computer account on-prem (a credential that the computer itself writes in the userCertificate attribute of its own computer account) to Azure AD in the form of a device object (holding that credential). After the device is created in Azure AD, the device will reach out to Azure AD for registration using that credential. If this process has not been completed by Azure AD Connect then registration will fail. If this is the case you can take a look at Azure AD Connect sync’ metaverse and see whether you find the computer sync’ing to Azure AD.
LikeLike
You are correct it is not federated. So if we have filtered our OUs to only sync OUs with user objects than the device won’t ever register? Is that correct? I would need the device OU syncing so that it sees it in the on-premise active directory?
LikeLike
That is correct. The computer account needs to be in scope for sync’ so it gets into Azure AD as a device object with the credential than later can be used to complete registration.
LikeLike
That was the issue. I was not syncing the OU where the devices were located within Azure AD Connect. I also had to open the synchronization service manager. Click on Connectors and then the on-premise domain to open the connector designer. Under select object types device was unchecked. Once I checked that box and ran a full import and full synchronization it began working completely.
Thank you for your help!
LikeLike
while running dsregcmd.exe /status then under user state ngcset = No . What it meant and how to resolve it . Any help will be appriciated.
LikeLike
NgcSet refers to whether the user has provisioned Windows Hello for Business (WHfB). Azure AD joined devices provision WHfB by default when the user signs in for the first time to the device. Hybrid Azure AD joined devices is off by default. There is Group Policy that you can enable, however there is additional configuration needed on-prem to support WHfB authentication to DCs. When the user provisions WHfB, NgcSet must show YES.
LikeLike
Hi there. All of our Devices have registered fine, but we are finding the odd users (User State) when running dsregcmd /status showing WamDefaultSet : Error.
This causes issues with modern apps, like for example Store opens with an error
Have tried dsregcmd /leave and then re-registered device, tried new user profile. Nothing seems to work.
Any ideas, thanks
LikeLike
+———————————————————————-+
| User State |
+———————————————————————-+
NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : ERROR
AzureAdPrt : YES
LikeLike
We are also having the same issues, did anybody manage to resolve this?
LikeLike
Jack, see my response to Kieren and see if you can try those steps.
LikeLike
Hi Jairo,
Thank you for the swift response.
The output from a non-elevated command prompt, returns the following:
NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : NO
AzureADPrt : NO
Looking in the event viewer, under the User Device Registration app logs, I’ve managed to find the following:
Event ID 318:
This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Password provisioning will not be enabled.
Cheers,
Jack
LikeLike
Kieren, can you run the command with the /debug parameter in a NON elevated command prompt window? Basically run from a command prompt window under the current logged-on user context:
dsregcmd.exe /status /debug
To get the value of WamDefaultSet the tools asks the Web Account Manager for the account that has been set as the default in Windows. ERROR would mean that the API call failed. The /debug switch will output the actual error.
LikeLike
Apologies for the hijack but our WamDefaultSet is also at an error state.
running dsregcmd.exe /status /debug (non-elevated) returned the foloowing error for me:
get_DefaultWebAccount returned nullptr. Default account is NOT set.
Any ideas?
LikeLike
Hi Lee, that suggests that the user didn’t authenticate successfully to Azure AD during sign-in to Windows (assuming AzureAdJoined is YES).
You can check that the WS-trust usernamemixed end-point is enabled and accessible by the device (used upon sign-in to Windows) (also assuming that the user can authenticate successfully to Office 365 or other Azure AD backed apps from any browser for example).
I have also seen issues on devices that have been upgraded from 1402 version of Windows where we were registering device state in a slight different manner and special keys provisioned in the TPM wouldn’t work in 1511 and others. You can try resetting the TPM and let the device register again.
BTW, since 1607 we added a field called AzureAdPrt to the output. Is your version 1511? if 1607 or above you should check better this value instead, although the WamDefaultSet can be used as well to check successful authentication.
LikeLiked by 1 person
Hi Jairo,
Thank you for the quick response. In anwser to your questions, we are trying to join our machines to azure ad with no luck.
WS-trust usernammixed is enabled and we can do everything else 365/Azure wise – users have SSO to Office 365, we can wokplace join users on windows 10 machines, Office 2016 is signed in and successfully links with OneDrive for business and our Machines are “Hybrid Azure AD Joined”
The machine I am currently using is version 1702 and we dont use TPM at all….
AzureADPrt states “No”
The only thing we cannot do is join the machine to Azure AD, we are currently trying to leverage this for our mobility users…..Event logs in “User Device Registration” ultimately give two errors – both Event ID 304 – “A specified authentication package is unknown”.
Aside from this there are some event logs about accessing the registry but not a lot else.
We have been banging our heads with this problem for a few weeks now.
Any ideas would be greatly appreciated
LikeLike
Hi Jairo, i am trying to find the big picture difference in features between “Azure AD Joined” and “Domain Joined” for DeviceTrustType, especifically about the Automatic Bitlocker encryption and subsequent key recorded in the Azure Portal. Can you point me in the right direction to get this information?
Thank you and best regards.
LikeLike
It is not explained as we are expecting.. you were able to find the difference?
LikeLike
if we see the Azure conditional access settings.. we have an option like “Require domain joined (Hybrid Azure AD)” so both the same ?
LikeLike
Raj, in the Azure AD conditional access UI, the option that reads “Require domain joined (Hybrid Azure AD)” will permit access to users on devices that are hybrid Azure AD joined but no Azure AD joined. Hybrid Azure AD joined devices are domain joined devices that have been registered with Azure AD and that as they already have a relationship with AD (on-prem) they are already managed by the organization (Group Policy, SCCM or others). Azure AD joined devices require an MDM like Microsoft Intune (part of Enterprise Mobility + Security or EMS) to be marked as ‘Compliant’. For differences between Azure AD joined and hybrid Azure AD joined (and Azure AD registered i.e. BYOD) see this document: https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction.
LikeLike
This document explains the differences between Azure AD joined, hybrid Azure AD joined and Azure AD registered devices: https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction. For BitLocker in particular, the key is escrowed to Azure AD automatically on Azure AD joined devices with certain capabilities. Hybrid Azure AD joined devices can escrow the key to Azure AD if the user manually selects so in Windows.
LikeLike
Hi Jairo,
Thanks for the really great background info on how all this works behind the scenes.
The main scenarios discussed are always
– AD Join and then AAD Join
– AAD Join only
However, would it technically be possible to switch the order of the first one around?
– AAD Join and then AD Join
My guess is that AAD Connect would struggle to correlate the objects in AD and AAD. Was hoping you might have some thoughts on this.
Thanks
LikeLike
Hi Jan, we currently have a hard block in the NetJoin API (the one that does domain join a.k.a. AD join) when the devices is already Azure AD joined. In other words, that path is not technically possible even if you tried. Any thoughts on why would you be interested in this path? I have heard some thoughts but wanted to see if you had any particular insights.
LikeLike
I’m configuring automatic registration of Windows domain-joined devices with Azure Active Directory according to https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup. Step 2 is a quite complicated step. However, I see in ADFS on Windows Server 2016 the following is available in the AD FS management console: AD FS > Service > Device Registration
Here right now it tells me “The Active Directory forest is not configured for device registration with this AD FS farm” and then you can press Configure device registration. Will this actually perform Step 2 for you?
LikeLike
Hi,
That option in AD FS 2016 is actually to enable device registration in AD FS itself. This is specifically intended for on-premises only organizations (organizations that don’t have Azure AD) to enable in particular Windows Hello for Business. That option won’t do step #2.
In terms of the complexity of step #2 we are looking for ways to make it simpler in the next update of Windows (RS4, this spring). Stay tuned!
Jairo
LikeLike
I wonder, then, is the Microsoft Sign in Assistant install still needed for end user devices? Does it have any function any more?
LikeLike
Pingback: How Domain Join is different in Windows 10 with Azure AD | [Azure] Active Directory by Jairo Cadena – More Stuff 2 Read [Quite Sparsely]
Pingback: #AzureAD device-based conditional access and #Windows 7/8.1 | [Azure] Active Directory by Jairo Cadena
Pingback: Setting up Windows Hello for Business with Intune – Micro-Scott – Blogging Windows and Device Management
Thanks for the great articles Jairo!
I wanted to ask you about a situation we are running into using the 3b option above and conditional access.
Setup:
AAD usernames are @emaildomain.com (Alternate ID).
Devices are @domain.com.
Devices are showing up in the Azure portal as Hybrid Domain Joined registered.
Scenario 1:
When user1@emaildomain.com attempts to sign in to the O365 portal on a domain joined PC, they are blocked by conditional access for not having a domain joined PC.
dsregcmd /status:
AzureAdJoined: Yes
KeySignTest: Passed
WorkplaceJoined: No
WamDefaultSet: No
AzureAdPrt: No
IsUserAzureAD: No
Scenario 2:
When user2@domain.com attempts to sign in to the O365 portal on a domain joined PC, they are granted access.
dsregcmd /status:
AzureAdJoined: Yes
KeySignTest: Passed
WorkplaceJoined: No
WamDefaultSet: Yes
AzureAdPrt: Yes
IsUserAzureAD: Yes
Are Alternate IDs support by Hybrid Domain Join and Conditional Access, or is Scenario 2 the only way it will work?
Thanks!
LikeLike
I think Jairo answered this question here – https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/comment-page-1/#comment-1991
LikeLike
Oh I missed that. Thank you!
LikeLike
Hi . we do not want to join AAD. we do have Azure AD connect for our office 365 integration and AD FS for single sign on. Nothing is setup to do device registration, and yet these 2 certificates are installed on workstations. We have checked the Azure AD configuration, we have checked the AD FS configuration, device registration is disabled. How can we stop workstations to try to join AAD and to stop receiving those certificates .?
thanks
LikeLike
Hi Michael,
There is a policy that you can push to your domain joined computers that will prevent them from registering to Azure AD. See this content and let me know if that doesn’t help: https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup#step-4-control-deployment-and-rollout.
Now, if I may, why don’t you want these registered with Azure AD? At a minimum you’ll get true SSO across Office 365 and Azure AD apps.
Jairo
LikeLike
Hi Jairo. Thanks for your reply. I have set that policy to disable. The issue is we use 802.1x for our network, and if there are 2 client authentication certificates in the computer personal store, the 802.1x authentication fails. If the computers join Azure AD, they get a client authentication certificate :).
Nothing was set to ENABLED as per what the documentations are saying about hybrid join, and yet computers started to register anyways.
Thanks
LikeLike
Michael, since 1607 the default behavior (default value of policy) is to register. In other words if the policy is absent the computer will attempt registration. If you have explicitly disable the policy (to not register), something that you might want to make sure is that the policy is set upon first boot of the computer (for example setting the policy in the image itself). For computers who have been already registered, you can run dsregcmd.exe /leave (e.g. via a GP script) after setting the policy to disable auto-registration. This way the certificate will be cleaned up and next boot the computer won’t attempt auto-registration again.
Now, said al that, I would be interested in learning more about the potential limitation based on the networking configuration you mention. Ideally there should be no conflict by having one extra (or even multiple) client auth certificates in the cert store if the right cert is sent to the server based on the right issuer. If you don’t mind sending me an email to jairoc at microsoft dot com I would include someone in the team that may be able to follow up on that.
Jairo
LikeLike
Hi Jairo,
I have W10 devices showing in the Azure portal as being hybrid Azure AD joined, they get a certificate but I never see the owner populated against the device. Device State of dsregcmd /status looks to be fine, User State NgcSet = No, EnterprisePRT = No. Ngc Prereq PolicyEnabled = No. PreReqResult = WillNotProvision. dsregcmd /debug /join tells me the device is already joined. Group Policy is in place for device registration & ADFS Claims Rules. I cannot see what else needs to be done to change PolicyEnabled = Yes & or get the User details populated.
I assume I should see the device associated with the user in Azure. What am I missing? Thanks
LikeLike
Hi Patrick, the association of a device with the user happens upon registration based on the user who joined the device. This is specially true for an Azure AD joined device in which a user who goes through OOBE (or Settings) with their user account and joins it to Azure AD will have this association. A hybrid Azure AD joined device is automatically registered even in the absence of a user by the computer identity itself. This is why you won’t see a hybrid Azure AD joined device with such an association. Said that the team has been thinking on ways to manage the association between computers and users in an easy and intuitive way (via PowerShell or Azure portal). There should be some improvements in the future in relation to this.
Jairo
LikeLike
Thanks Jairo, appreciate the response.
LikeLike
I have this working, but is there a way to automate it on new computers that staff are setting up in remote offices? They are stand alone, maybe with Autounattend.xml It also looks like it caches the logins that is good because my remote offices are often offline. Thanks Scott
LikeLike
Hi Scott,
Are these remote offices computers joined to the domain? If the computers that staff are getting in remote offices are not joined to a domain (not sure if this is what you meant with stand alone) a good option to consider might be deploying Azure AD joined devices instead.
Jairo
LikeLike
Yes, they are in an office in another country with no connection to our AD. Are there any options to automate the connection to Azure AD join? I have 30 small offices in different countries with really no local IT staff.
Thanks.
LikeLike
Scott, one option would be to have users in those offices to configure new devices using their Azure AD accounts during the out-of-box-experience (OOBE). This will register the device with Azure AD and enroll the device into the MDM (e.g. Intune). You can also take a look at AutoPilot (https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/windows-10-autopilot) to have pre-registered devices sent to these users so the devices join only to your organization.
LikeLike
Hello! I’ve been trying to get this setup for a while and am stumped on an issue. my domain controller is currently at ad.domain.com. the devices are also on the ad.domain.com. users login with @domain.com UPN. i’m trying to implement windows hello for business. currently the domain is:
Azure AD hybrid connected via Azure AD connect, federated at ad.domain.com. configured with ADCS.
ADFS on premises. at sts1.ad.domain.com
Proxy for ADFS is at fs.domain.com
authenticating with azure ad works on devices through the web to our web proxy and allow user login to online services. even azure MFA works. however, when i try to join a computer to enable windows hello for business it fails with errors. primarily:
from the event log:
Warning: Event 362
Message Windows Hello for Business provisioning will not be launched.
DeviceIsJoined Yes
AADPrt Yes
NgcPolicyEnabled Yes
NgcPostLogonProvisioningEnabled Yes
NgcHardwarePolicyMet Yes
UserIsRemote Yes
LogonCertRequired Yes
ADFSRaReady No
RATemplateReady Not Tested
ADFSPrtPresent Yes
MachinePolicySource enrollment authority
I have no idea why. is this related to the claim issuance policy for relaying party trusts?
is it because my computers on a sub domain?
i initially thought it was because of bad claims, but i cannot verify since the instructions from the link below don’t really apply to an already joined domain from azure ad connect. regardless, login works so i assumed i configured it correctly.
https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup
i also looked at the instructions here, but again, the claims don’t match what was pre-generated via azure ad connect. (and again, basic login works)
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id
(btw the links are all from the how to setup windows hello for business directions)
i thought it might be certificate related at one point but the certificate piece is fairly straight forward and i can’t find anything wrong.
Thoughts?
Thanks!
LikeLike
Hi Don, for hybrid Azure AD joined devices (domain joined + registered with Azure AD) you need to explicitly set the policy to trigger provisioning of Windows Hello for Business. Take a look at the deployment guide here: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-guide. Based on your description follow one of the Hybrid Trust deployment models (key trust or cert trust). If you have AD FS in Windows Server 2016 and you have your PKI infrastructure you may be good following the cert-trust model.
LikeLike
I also used to get this error but it changed to what i posted above ,after i messed with the settings for the endpoints. “Enterprise user logon certificate template is : Not Tested ”
full event log below:
Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: No
Enterprise user logon certificate template is : Not Tested
User has successfully authenticated to the enterprise STS: Yes
Certificate enrollment method: enrollment authority
LikeLike
and wow. sorry for the triple post. i also had reinstalled ADFS through azure ad connect with settings for key trust for the newer error where i believe i was on certificate trust on the second posted older error. regardless, it appears they are essentially the same.
LikeLike
Don, check my previous response. It seems you may be missing just the Group Policy Object to trigger provisioning of Windows Hello for Business. If you have SCCM you can push the setting as explained in this article: https://docs.microsoft.com/en-us/sccm/protect/deploy-use/windows-hello-for-business-settings. If you want to use Group Policy (or even MDM) take a look at this article: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.
LikeLike
Dumb question – if my Laptop is Azure AD joined, and I am on a plane, not on the Internet, can I authenticate to my laptop to use it offline?
LikeLike
Yes, you can. Sign in to the device happens via cached logon.
LikeLike
I tested this, it Caches the login information just Like AD. Not sure if it is the Same Registry key on how many to keep but it works.
LikeLike
Does DRS azureadjoin or workplace join or whatever its called via ADFS time out? We have conditional access policies and we have a situation where devices in the field still show as registered when you run dsregcmd /status yet are not granted access as the CA rules say they need to be “Domain Joined” This happens randomly after a few months out in the field. Do the devices need to hit the intranet interface of ADFS periodically to “reconfirm” registration?
Thanks
LikeLike
Hi, registration is a one time operation that doesn’t need to be refreshed afterwards. On the device you might want to check that the output of dsregcmd.exe /status for AzureAdPrt shows as YES. The PRT contains the device ID for Azure AD to identify the device for conditional access. If it is NO there was an issue during authentication with Azure AD upon Windows Logon. You also might want to check that the device object in Azure AD exists and shows its deviceTrustType as domain joined (i.e. Hybrid Azure AD joined).
LikeLike
Hi Jairo,
We recently tried setting this up in our lab environment and ran into something called Synchronized Join. I am running the latest version of Win10 (rs04) and Win Server 2016 R2. Is this something new? My AAD tenant is federated with a 3rd party provider and I have PTA and PW Hash Sync disabled. The join through federation broker fails and it falls back to this “Synchronized Join.” From what little info there is on the net, it sounds it happens due to userCert field populated. Can you shed some light into what this new functionality is?
Thanks!
LikeLike
Dali, Azure AD Connect will take domain joined computer objects in AD on-premises and will synchronize then as device objects in Azure AD. These objects are there for the non-federated case (where there is no AD FS or STS on-premises). In this case the device will attempt registration with Azure AD after it joins the domain on-premises using a credential that it generates locally and writes into AD on-prem on its own computer account in the userCertificate attribute. Azure AD Connect as part of the sync’ to a device object to Azure AD will take this credential and will put in in the device object it creates as part of synchronization of the computer account. When the device reaches out with this credential to Azure AD (Azure Device Registration Service (Azure DRS) to be precise), Azure DRS will look for the device object previously written by Azure AD Connect and will check that the credential is valid to the complete registration. This would apply to PTA with PW hash sync disabled. You can make sure your computers are on a OU that are in the scope of sync’ for Azure AD Connect and see that device objects for domain joined computers are being created in Azure AD.
LikeLike
Couple of questions:
a) “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.” in section “(3b) Device authenticates itself to Azure AD (when Azure AD SSO configuration is password hash sync’ i.e. no AD FS)”
Is this done for federated domains as well?
Output from dsregcmd.exe /join /debug running as system
TenantInfo::Discover: IDP auth URL and auth code URL contain different hosts. Tenant is federated.
TenantInfo::Discover: Join Info { TenantType = Federated; AutoJoinEnabled = 1; TenandID =
Even if identity provider is not generating the claims. The device still registers using a synchronized join flow.
wmain: federated ADRS join failed. Try synchronized join.
wmain: completed successfully
DSREGCMD_END_STATUS
AzureAdJoined : YES
EnterpriseJoined : NO
Based on what we are seeing and your explanation, it seems like the device is authentication itself to Azure AD via the managed domain route. Is this expected change in behavior?
b) For “(3) Device authenticates itself to Azure AD via AD FS to get a token for registration”
Microsoft documentation says computer object should already be synced to AAD using AAD connect.
What I am seeing is the computer object is synced from AD to AAD via AAD connect tool if userCertificate property is enabled. Is the expectation that the customers in federated scenario have to tweak the sync rule to make sure the device can synchronize?
If the object is not synchronized to AAD when dsregcmd command is run, we get the following error
The get join response operation callback failed with exit code: Unknown HResult Error code: 0x801c03f2.
Activity Id:
The server returned HTTP status: 400
Server response was: {“ErrorType”:”DirectoryError”,”Message”:”The device object by the given id () is not found.”,”TraceId”:,”Time”:””}
LikeLike
Please ignore the second part question. The failure appears to be happening in the synchronized join flow path that is triggered automatically after the federation flow fails.
LikeLike
Hi Tarun,
In respect to (a), yes, this is a new behavior since Windows RS4 release. The intention of this feature was to solve the complexity some customers experienced when creating the AD FS/3rd party STS rules for device registration. Since RS4 the issuance transform rules in AD FS or equivalent in a 3rd party STS, are now optional. The rules will give you instant registration vs. waiting a couple of hours or so for Azure AD Connect to bring the device up to the cloud. This, however, may work just fine for many organizations given that by the time the user receives the device already joined, the device has already been created in the cloud (device has been joined by an admin beforehand for example).
The userCertificate property is the signal that tells Azure AD Connect to consider the computer account to be on the scope of synchronization to Azure AD. In the non-federated case, of course this is needed to create the device object in Azure AD so the computer later on registers itself against Azure AD. In the federated case (and the non-federated after the device has been registered) it allows the computer account to be in sync’ with the device object in Azure AD (e.g. if the computer is disabled on-prem then the device is disabled in Azure AD).
Jairo
LikeLike
Thanks a lot Jairo for your time. Your talks on the topic and blog are of great help.
I have a few follow up questions hopefully you will have a chance to look at them.
Since RS4 the issuance transform rules in AD FS or equivalent in a 3rd party STS, are now optional.
Question: What we are seeing a few differences when the device joins via the STS flow and the new synchronized join flow (that gets triggered when STS flow fails.) The most evident one is Window Hello for Business Pin does not get provisioned. In the user device registration event log we see “user logged in with AAD credential” as false after the device is shown as registered in AAD. Is this expected to work with the new flow or it might be configuration issue? For federated join devices pin gets provisioned and user is able to sign in using it.
Regarding: The rules will give you instant registration vs. waiting a couple of hours or so for Azure AD Connect to bring the device up to the cloud.
The flow as I am seeing: For “synchronized join flow” the first attempt fails to register the device to AAD since object is not present in AAD. This attempts results in device populating user certificate attribute in AD. This computer object is then picked up AAD connect in the next sync cycle and it gets joined to AAD. An attempt to register the device now will succeed as object is present in AAD and can be authenticated.
For federated flow, if STS issues the valid saml token the device is instantly created in AAD and it shows up as registered.
So it appears synchronized join flow is then not as fast as federated flow. Is my understanding of the flow incorrect?
Can you share any information on what configuration are needed in AAD connect for synchronized join flow to work? (How different is it from managed domain flow which requires PTA.) I don’t have any feature enabled except device write back policy to get the key from AAD back to AD to enable Windows Hello for Business log in with PIN and the synchronized flow is getting triggered.
When can we expect the documentation to reflect these changes?
LikeLike
Hi Jairo! This is great and thank you for the response! A few questions:
1. When should customers use instantaneous/federated v. sync join (where instantaneous is when we use AD FS or 3rd party STS)? In other words, why would customers need instantaneous/federated join over sync join?
2. Why is sync join a fail-over and not the primary way to achieve hybrid join?
Sai
LikeLike
Jairo,
question on the topic,
We have the problem that when we re-image machines with SCCM, the machine bocomes N/A in AAD, and we can’t start the applications outlook and excel e.g.
When we delete de device in AAD and re-join the onprem AD the machine is getting back in AAD and working like a charm again.
How can we re-image devices with sccm and get a good AAD registration?
We have AAD Connect and ADFS also running in the network.
regars
Roger
LikeLike
Jairo,
question on the topic,
We have the problem that when we re-image machines with SCCM, the machine bocomes N/A in AAD, and we can’t start the applications outlook and excel e.g.
When we delete de device in AAD and re-join the onprem AD the machine is getting back in AAD and working like a charm again.
How can we re-image devices with sccm and get a good AAD registration?
We have AAD Connect and ADFS also running in the network.
regads
Roger
ps: sorry had wrong email adres excuus for the dubble post/.
LikeLike
Hi Jairo,
Hope you are doing well.
Recently we have set up the SSPR and users are able to reset their password using Portal however when they try to reset the password from Windows 10 machine. They gets error stating that something went wrong. Device is showing Hybrid Azure AD Joined.
When we ran dsregcmd /status all looks fine except.
WamDefaultSet : NO
AzureAdPrt : NO
Kindly advise.
LikeLike
We are getting the following error.
OAuth response error: invalid_request
Error description: AADSTS70002: Error validating credentials. AADSTS130004: UserPrincipal doesn’t have the NGC ID key configured.
Any thoughts
LikeLike
Did you ever get this resolved?
LikeLike
Pingback: KeySignTest Failure & Device Registration – Modern Workplace Configuration with Intune
Pingback: Setting up Windows Hello for Business with Intune – Blogging about Windows Device Management with Intune
Hi,
Thanks for the wonderful post!! I was wondering if you might be able to assist me. On user first time setup, for some reason AzureADPrt isn’t automatically being used… For example, when I UNC to a network share (over vpn) it asks for the username and password. If I reboot or lock the machine and re-enter my details on logon, UNC auto authenticates fine.
It seems for whatever reason, the first time login is using something else for authentication or the AzureADPrt isn’t being used by default. I can see that the AzureADPrt is stated YES. would you happen to know anything about this or seen this before? I have been stuck on it for a few weeks now…
Thanks,
Mark.D
LikeLike
Pingback: KeySignTest Failure & Device Registration – Modern Workplace Configuration
I have one user who had to unjoin/rejoin his computer from the domain, and now WHFB doesnt work. When I look at the logs everything looks ok except for this line:
No
I have been scratching my head trying to find how what “HardwarePolicy” is not met. This computer was using WHFB just fine and the problem started after the domain rejoin, so hardware is the same.
Any help will be appreciated.
LikeLike
hi, we are facing strange problems within hybrid join and thought, maybe you can help, as we didn’t find any useful post on the http://www…..
we have a federated setup and the AD sync from local to AAD is working fine. we have all users, groups and devices available.
if we try to hybrid join via dsregcmd.exe, we always face the below error: (we changed the Tenant informations to anon)
_______________________________________________________________________________
C:\WINDOWS\system32>dsregcmd /join /debug
dsregcmd::wmain logging initialized.
DsrCmdAccountMgr::IsDomainControllerAvailable: DsGetDcName success { domain:OUR-Domain.com forest:OUR-Forest.com domainController:\\OUR-Domain-Controler.com isDcAvailable:true }
PreJoinChecks Complete.
preCheckResult: Join
isPrivateKeyFound: undefined
isJoined: undefined
isDcAvailable: YES
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: undefined
elapsedSeconds: 1
resultCode: 0x0
Automatic device join pre-check tasks completed.
TenantInfo::Discover: Join Info { TenantType = Managed; AutoJoinEnabled = 1; TenandID = OUR-Tenant_ID; TenantName = OUR_Tenant.onmicrosoft.com }
Join request ID: b9c4e6af-523a-4571-9bb0-5b407fd5416c
Join response time: 10-22-2019 12:01:18Z
Join HTTP status: 400
Join error code: DirectoryError
Join message: The public key user certificate is not found on the device object with id: (876325ec-3bb2-4cac-9b37-94d8ec60c647).
DsrDeviceAutoJoin failed 0x801c03f2.
DsrCmdJoinHelper::Join: DsrCmdDeviceEnroller::AutoEnrollSync failed with error code 0x801c03f2.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO
_______________________________________________________________________________
Event Log: (User Device Registration)
Automatic registration failed at join phase.
Exit code: Unknown HResult Error code: 0x801c03f2
Server error: The public key user certificate is not found on the device object with id: (876325ec-3bb2-4cac-9b37-94d8ec60c647).
Tenant type: Managed
Registration type: sync
Debug Output:
joinMode: Join
drsInstance: azure
registrationType: sync
tenantType: Managed
tenantId: OUR TENANT
configLocation: undefined
errorPhase: join
adalCorrelationId: undefined
adalLog:
undefined
adalResponseCode: 0x0
————————————————————————————————————————
The get join response operation callback failed with exit code: Unknown HResult Error code: 0x801c03f2.
Activity Id: b9c4e6af-523a-4571-9bb0-5b407fd5416c
The server returned HTTP status: 400
Server response was: {“ErrorType”:”DirectoryError”,”Message”:”The public key user certificate is not found on the device object with id: (876325ec-3bb2-4cac-9b37-94d8ec60c647).”,”TraceId”:”b9c4e6af-523a-4571-9bb0-5b407fd5416c”,”Time”:”10-22-2019 12:01:18Z”}
____________________________________________________________________________
do you have any suggestions, what can cause the problem?
regards michael
LikeLike
I can tell you that this “feature” fails miserably in a healthcare environment where Intune is also employed.
LikeLike
Hello Jairo
Today my environment come up with a bunch of devices getting this Error:
Our environment is federated, is this an Error on the ADFS farm?:
Log Name: Microsoft-Windows-AAD/Operational
Source:AAD
Event ID: 1098
Error: 0xCAA90014 Server WS-Trust response reported fault exception and it failed to get assertion
Error message from WS-Trust response: The requested resource requires user authentication.
Logged at wstrusttokenrequest.cpp, line: 103, method: WSTrustTokenRequest::AcquireToken.
Request: authority: https://login.microsoftonline.com/common, client: AB9B8C07-8F02-4F72-87FA-80105867A763, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/AB9B8C07-8F02-4F72-87FA-80105867A763, resource: https://officeapps.live.com, correlation ID (request): 9ab2bb49-b9ef-4b72-a578-e3e99fd9cf90
Log Name: Microsoft-Windows-AAD/Operational
Source:AAD
Event ID: 1025
Http request status: 500. Method: POST Endpoint Uri: https://%mycompanydomain%.com/adfs/services/trust/13/usernamemixed Correlation ID:
—————————————————————
Log Name: Microsoft-Windows-AAD/Operational
Source:AAD
Event ID: 1088
WSTrust response error: InternalServiceFault
Error description: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.
LikeLike
Having an issue where a user on an AAD joined laptop (not hybrid joined) is suddenly getting logged out of the install Office apps, including Teams and OneDrive and can’t sign back in. The can log in to office.com and access all of the apps just fine. Verified that she is assigned the proper o365 license (O365 standard) to use the apps. Having the user sign out and back into the app fails to authenticate. Support tried also tried reinstalling the apps.
Output of dsregcmd /status shows User State WamDefaultSet : ERROR (0x80090013).
LikeLike
I have the same error. Do you have a solution?
LikeLike
The info in the link below fixed our issues with MS Office apps not being able to authenticate on AAD joined devices. 3rd party antivirus was causing the problems.https://www.reddit.com/r/sysadmin/comments/112ytzh/ms365_office_app_login_issues_since_monday/
LikeLike