Connect domain-joined devices to Azure AD for Windows 10 experiences

Domain join is the traditional way organizations have connected devices for work for the last 15 years and more. It has enabled users to sign in to their devices by using their Windows Server Active Directory (Active Directory) work or school accounts and allowed IT to fully manage these devices. Organizations typically rely on imaging methods to provision devices to users and generally use System Center Configuration Manager (SCCM) or Group Policy to manage them.

Domain join in Windows 10 will provide the following benefits after you connect devices to Azure Active Directory (Azure AD):

  • Single sign-on (SSO) to Azure AD resources from anywhere
  • Access to the enterprise Windows Store by using work or school accounts (no Microsoft account required)
  • Enterprise-compliant roaming of user settings across devices by using work or school accounts (no Microsoft account required)
  • Strong authentication and convenient sign-in for work or school accounts with Microsoft Passport and Windows Hello
  • Ability to restrict access only to devices that comply with organizational device Group Policy settings

Prerequisites

Domain join continues to be useful. However, to get the Azure AD benefits of SSO, roaming of settings with work or school accounts, and access to Windows Store with work or school accounts, you will need the following:

  • Azure AD subscription
  • Azure AD Connect to extend the on-premises directory to Azure AD
  • Policy that's set to connect domain-joined devices to Azure AD
  • Windows 10 build (build 10551 or newer) for devices

To enable Microsoft Passport for Work and Windows Hello, you will also need the following:

As an alternative to the PKI deployment requirement, you can do the following:

  • Have a few domain controllers with Windows Server 2016 Active Directory Domain Services.

To enable conditional access, you can create Group Policy settings that allow access to domain-joined devices with no additional deployments. To manage access control based on compliance of the device, you will need the following:

  • System Center Configuration Manager version 1509 for Technical Preview for Passport scenarios

Deployment instructions

Step 1: Deploy Azure Active Directory Connect

Azure AD Connect will enable you to provision computers on-premises as device objects in the cloud. To deploy Azure AD Connect, refer to "Install Azure AD Connect" in the article Integrating your on-premises identities with Azure Active Directory.

  • If you followed a custom installation for Azure AD Connect (not the Express installation), then follow the procedure Create a service connection point in on-premises Active Directory, later in this step.
  • If you have a federated configuration with Azure AD before installing Azure AD Connect (for example, if you have deployed Active Directory Federation Services (AD FS) before), then follow the Configure AD FS claim rules procedure, later in this step.

Create a service connection point in on-premises Active Directory

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:

Copy
 
Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";

$aadAdminCred = Get-Credential;

Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;

When running the cmdlet $aadAdminCred = Get-Credential, use the format user@example.com for the user name of the credential that's entered when the Get-Credential pop-up appears.

When running the cmdlet Initialize-ADSyncDomainJoinedComputerSync ..., replace [connector account name] with the domain account that's used as the Active Directory connector account.

Configure AD FS claim rules

Configuring the AD FS claim rules enables instantaneous registration of a computer with Azure device registration service by allowing computers to authenticate by using Kerberos/NTLM via AD FS. Without this step, computers will get to Azure AD in a delayed manner (subject to Azure AD Connect sync times).

Note

If you don’t have AD FS as the federation server on-premises, follow the instructions of your vendor to create the claim rules.

On the AD FS server (or on a session connected to the AD FS server), run the following PowerShell commands:

Copy
 
  <#----------------------------------------------------------------------
 |   Modify the Azure AD Relying Party to include the claims needed
 |   for DomainJoin++. The rules include:
 |   -ObjectGuid
 |   -AccountType
 |   -ObjectSid
 +---------------------------------------------------------------------#>

$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules

$rule1 = '@RuleName = "Issue object GUID"
      c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
      c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
      => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), query = ";objectguid;{0}", param = c2.Value);'

$rule2 = '@RuleName = "Issue account type for domain joined computers"
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
      => issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Value = "DJ");'

$rule3 = '@RuleName = "Pass through primary SID"
      c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
      c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
      => issue(claim = c2);'

$updatedRules = $existingRules + $rule1 + $rule2 + $rule3

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString
Note

Windows 10 computers will authenticate by using Windows Integrated authentication to an active WS-Trust endpoint hosted by AD FS. Ensure that this endpoint is enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can do this by checking the adfs/services/trust/13/windowstransport. It should show as enabled in the AD FS management console under Service > Endpoints.

Step 2: Configure automatic device registration via Group Policy in Active Directory

You can use Group Policy in Active Directory to configure your Windows 10 domain-joined devices to automatically register with Azure AD.

Note

For latest instructions on how to set up automatic device registration see, How to set up automatic registration of Windows domain joined devices with Azure Active Directory.

This Group Policy template has been renamed in Windows 10. If you are running the Group Policy tool from a Windows 10 computer, the policy will appear as:
Register domain joined computers as devices
The policy is in the following location:
Computer Configuration/Policies/Administrative Templates/Windows Components/Device Registration