Jan Ketil SkankeDomain joining a PC has been the way for companies in a long time to make sure they have a common identity inside their network and control of the PCs in their network. This does not change with Windows 10. However new possibilities come to play when Azure AD becomes a part of the picture.
- You get Single Sign On (SSO) towards work resources in the cloud. That means that users don’t receive any authentication prompts when they access resources like Office 365 portal and other federated Azure SaaS apps (myapps.microsoft.com) from outside the company network. And you will also get SSO from inside your company network without using ADSF as you need to do today.
- Enterprise roaming of user settings between devices. The user setting no longer roam via you Microsoft Account (MSA), but now uses your AzureAD for roaming. This means that you don’t need an MSA to enable synchronization of setting. (This feature is not available in Azure AD as of today, but should be coming soon.
- Access to Windows Store for business using AD Account enabling the users to download and install the preselected apps of their company from the companys partion of the Windows Store without using an Microsoft Account
- Microsoft Passport for Work and Windows Hello
- Conditional Access to both On-premises and Cloud resources like SaaS Apps and E-Mail.
To make this magic happen you will need the latest version of AAD Connect and a Group Policy. When this is in place the domain joined Windows 10 computer will automaticly register in Azure AD.
So how to this work?
When the Group Policy is applied on the Windows 10 Computer the device registration will trigger. If the policy is configured on Windows 10 it is located at:
Computer Configuration/Policies/Administrative Templates/Windows Components/Device Registration
If the policy is configured from a Windows Server 2012 R2 it is located at:
Computer Configuration/Policies/Administrative Templates/Windows Components/Workplace Join
The Group Policy will create a task in Task Scheduler on the device with the name Automatic-Device-Join. This task which run as SYSTEM reaches out to AD using the computer identity to find Azure AD tenant information. For more detailed information please take a look at Connect domain-joined devices to Azure AD for Windows 10 experiences
Now the computer authenticates it self to Azure AD either through ADFS or directly if you have configured you enviroment without ADFS using password hash sync.
ADFS
If you are using ADSF the device authenticates to Azure Device Registration Service (DRS) using Windows Integrated Authentication (Kerberos). Claims are passed to Azure AD via ADSF during authentication and are written as attributes in the newly created device object. The attributes are Object GUID and SID of computer object on-prem and Claims stating that computer is domain joined.
If you are not using ADSF the task will create a credential in the form of a self-signed certificate and will register the computer via LDAP in the userCertificates attribute. AAD Connect detects that the computer has registered this credentials and syncs this to Azure AD as a device object holding this credential, the object GUID and the Computer SID. The task will use this credentials to authenticate to Azure DRS directly once the device is created in Azure AD.
There will be a delay between when the policy is applied on the computer and the device ready for regsitration. This is because information needs to sync up via AAD Connect in this scenario.
The task will generate 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. If the device has a TPM the private keys will be hardware protected on the device.
Finaly the task sends the CSR obtaining the certificate and places it in the LocalMachine\My store and a device object is created in Azure AD with the certificate thumbprint associated with it.
Now the user will enjoy the new features I started with and IT will also be able to restrict access to only devices that are domain joined or compliant.
Nickolaj Andersen
Maurice Daly
Sandy Zeng
Michael Mardahl
I am seeing the following error when I run this command under SYSTEM context. Any suggestions on troubleshooting the DRS discovery for the tenant info?
dsregcmd.exe /debug
dsregcmd::wmain logging initialized.
DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domain:domain.internal forest:domain.internal domainController:\\MYDC.domain.internal 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: DsrBeginDiscover failed. 0x80072f8f
wmain TenantInfo::Discover failed with error code 0x801c0021.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO
You need to verify that your devices are synced to Azure AD. The Device OU needs to by in sync scope. Also you can see in Eventviewer under Applications and Services logs-Microsoft-Windows-AAD for errors. I see this specific error if the device is not synced to AAD.
Sounds great.
Does it mean every Azure AD users who logs on an AD DS joined computer will be automatically workplace joined?
Nice Article. How it help to developer in terms of balance the day to day life.
How can you view Win 10 devices on azure ad that are both domain and azure joined?
Also, if you try to enable Bitlocker it prompts you to save the key on the cloud. How can I view the key since in this case the device is not tied to a specific user?
[…] Why and how you should register your Windows 10 Domain Joined PC’s with Azure AD […]
Will this also work for Windows 8.1 clients?
Not the same way. You can register them with AzureAD, but that’s mostly for Conditional Access policies to work as expected.
https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-automatic-device-registration-windows-8-1/
When you say not the same way do you mean that there’s no possibility of SSO? Do Windows 7 and 8.1 clients using password sync behave in a similar fashion to Windows 10 in regards to the scheduled task? That is auth, create a self-signed cert and copy that via LDAP to the userCertifcates attribute of the computer object?
The reason I ask is we’re using password sync and have successfully auto registered a Win 10 PC but are still scratching our heads on the Win 7 PC. It seems to be hanging at the auth piece according to the event log errors (400’s and 404’s).
Windows 7 machines requires you to install a MSI to register.
More info here: https://azure.microsoft.com/nb-no/documentation/articles/active-directory-conditional-access-automatic-device-registration-windows7/
Windows 8.1 info here:
https://azure.microsoft.com/nb-no/documentation/articles/active-directory-conditional-access-automatic-device-registration-windows-8-1/
You will not get the same SSO experience without using ADFS on Windows 7 and Windows 8.1
Interesting read. Thanks.
When I run with the /debug paramter, it get this:
DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domain:danfoss.net forest:dfroot.net domainController:\DKDN01DCxx.xxxx.yyy isDcAvailable:true }
wmain TenantInfo::Discover failed with error code 0x80070057.
Any idea?
First question: are you running the command in System and not as a user?
Second question: Have you setup the SCP for AAD Registration to work?
Domain-joined devices will use the service connection point to discover Azure AD tenant information at the time of automatic registration with the Azure device registration service.
On the Azure AD Connect server, run the following PowerShell commands:
Import-Module -Name “C:Program FilesMicrosoft Azure Active Directory ConnectAdPrepAdSyncPrep.psm1”;
$aadAdminCred = Get-Credential;
Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;
For more details look here: https://azure.microsoft./en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/
Hi
Thanks for the article.
I am done all the configuration but still untill to join the devices(windows 10) to Azure AD. And I do not see the scheduled task on the client devices(win 10) . Group polices has been modified to apply the auto devices registration settings. Is there any way to troubleshoot?
Thanks heap
The first you need to do is to check / find the scheduled task in Task Scheduler, it should be in this location:
MicrosoftWindowsWorkplace Join
If should also have a status of Ready and trigger at logon of any user. Here you can also see the last run result.
If you want to do some more troubleshooting you can also manually run the command in the task with debug flag in a admin command prompt:
%SystemRoot%System32dsregcmd.exe /debug
Look at the output and see if you find any errors.