Why and how you should register your Windows 10 Domain Joined PC’s with Azure AD

  • [アーティクル]

It has been a while since my last blogpost as I have been on parental leave with my 1 year old son. I have also got a new employment since then and are now working for Lumagate AS in Norway as a Senior Consultant. Over to the important stuff :)

Domain 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 MSA.capture20160120095957042
  • Microsoft Passport for Work and Windows Hello
  • Conditional Access to both Onprem and Cloud resources like SaaS Apps and 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.

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.

 

 

 

Filed under: AzureAD, Client, Cloud, SSO, Windows 10 Tagged: AzureAD, Cloud, Identity, Join, Lumagate, Microsoft, Technical, Windows 10