Automatic Azure AD device registration for Windows 10 devices

Automatic Azure AD device registration for Windows 10 devices

Published: 12/14/2018

Overview


Azure Active Directory (Azure AD) device registration is the foundation for device-based conditional access scenarios. When a device is registered, Azure AD provides it with an identity that is used to authenticate it when the user signs in. The authenticated device and the device attributes can then be used to enforce conditional access policies for applications. When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This allows you to create additional conditional access rules that enforce access from devices to meet your standards for security and compliance. 

If you have an on-premises Active Directory environment, you can join your domain-joined devices to Azure AD, by configuring hybrid Azure AD joined devices. You can configure Windows devices to automatically register to Azure AD. Windows current devices use active STS (WS-Trust) workflow for Azure AD device registration. Therefore, the required configuration is different compare to Windows down-level devices, which utilize passive workflow (WS-Federation) for this process. 

Windows current devices are:

 
  • Windows 10
  • Windows Server 2016

Important: Automatic Azure AD device registration works only for domain-joined Windows devices.


The entire automatic registration process with Azure AD consists of two main stages:
 

Stage 1: Device registration.

The device authenticates to Azure Device Registration Service (DRS) via PingFederate using Kerberos Token Processor. PingFederate issues a token to Azure AD and then Azure AD issues the final token for Azure DRS. A set of attributes is passed to Azure AD in the response token when the computer authenticates, which are written as attributes in the newly created Azure AD device object. 

Azure AD Connect will later write back some attributes to a registered computer object in on-prem Active Directory. This is needed for a life cycle of the device object which is authoritative on-prem. The device generates a private/public key pair to be used in a certificate signing request (CSR) to Azure DRS to obtain a certificate that the device will use to authenticate to Azure AD.
 
In addition, the device generates a second private/public key pair that is used to bind the Primary Refresh Token (PRT) to the physical device upon authentication. This removes the risk of the token replay on other devices.
The PRT is the token used to provide SSO when users on this device access Azure AD applications. 



Stage 2: User registration.

The main goal of this stage is to obtain a PRT which will be used in the authentication workflows.
Depending on what credentials are used, a special plug-in will obtain the PRT via distinct calls to Azure AD and PingFederate. In this article, we assume that username and password are used.

To obtain the Azure AD PRT using username and password, the plug-in will send credentials directly to PingFederate server, specifically to the Username Token Processor endpoint. PingFederate server authenticates the user and sends back a WS-Trust assertion. Azure AD will verify the token obtained from the PingFederate server, build a PRT with both user and device attributes and return it back to the Windows device.


Here are the steps to configure automatic Azure AD device registration for Windows current devices with PingFederate server:
 


Note: These configuration steps are based on the following Microsoft article:

Configure hybrid Azure Active Directory joined devices manually.



Assumptions​


This article assumes a pre-existing environment that meets Microsoft requirements. It is expected that you already have:
 
  • PingFederate server running version 8.4 or later.
  • An Office 365 federated domain with appropriate subscriptions.
  • A fully functional WS-Federation/WS-Trust connection to Office 365 configured on the PingFederate server.
  • Both Username and Kerberos Token Processors are functional and in use for authenticating Office 365 users.
  • Azure AD Connect running for Active Directory synchronization with Azure AD.
 
 

Prepare Azure AD for automatic device registration



1. Set up a service connection point.
 
Detailed steps can be found in this Microsoft Article:
Configure hybrid Azure Active Directory joined devices manually.

Note:  Microsoft introduced a new wizard which can complete this step automatically. For more information see:
Configure hybrid Azure Active Directory join for federated domains.

 
2. Make sure that enterpriseregistration CNAME record is configured on your DNS server.
 
For more information, see this Microsoft Article: Create DNS records for Office 365 using Windows-based DNS.

3. Enable Azure DRS:

a) Open the Microsoft Azure portal.
 
b) Navigate to Azure Active Directory > Users and groups > Device settings.
 
c) Set the Users may join devices to Azure AD policy to All.

d) Set the Users may register their devices with Azure AD policy to All.

e) Click Save.


4. Verify that you are running an up-to-date version of Azure AD Connect.
 
 
 


Configure PingFederate server



1. Add the required attribute namespaces.
 
Note: In the PingFederate cluster, the steps in this section should be performed on the Admin node only.
 ​
a) Stop the PingFederate server.
 
b) Navigate to the following directory:
 
<pf_install>/pingfederate/server/default/data/config-store 
 
c) Open custom-name-formats.xml file in a text editor.
 
d) Add the lines listed below to the sts-attribute-namespaces section if they are not already present:
 
<con:item name="http://schemas.microsoft.com/identity/claims">http://schemas.microsoft.com/identity/claims</con:item>
<con:item name="http://schemas.microsoft.com/ws/2012/01">http://schemas.microsoft.com/ws/2012/01</con:item>
<con:item name="http://schemas.microsoft.com/claims">http://schemas.microsoft.com/claims</con:item>

e) Save changes.
 
f) Start the PingFederate server instance.
 
Note: In the PingFederate cluster, open the Administrative Console and populate the changes to all engine nodes, by clicking Cluster Management > Replicate Cluster Configuration.
 

2. Make sure that Omit Line Breaks in Digital Signatures option is configured on the PingFederate server (all engine nodes in the cluster configuration).  

 
For more details and instructions see PingFederate Integration with Office 365 Integration Guide.


3. Extend list of the LDAP Binary Attributes:

a) Open the PingFederate Administrative Console.

b) Navigate to Server Configuration > Data Stores.

c) Click the LDAP data store.

d) Go to the LDAP Configuration tab and click on Advanced.

e) Click the LDAP Binary Attributes tab.

f) Type objectSid (case sensitive) and click Add.

g) Click Save.
 
User-added image



4. Confirm the default token type for WS-Trust protocol:
 
a) Open the existing Office 365 SP connection.

b) Navigate to SP Connection > WS-Trust STS > Protocol Settings.

c) Make sure that Default Token Type is set to SAML 1.1 for Office 365. If it is not, select it from the drop-down menu and click Save

Note: This token type is available starting PingFederate 8.4.


5. Extend WS-Trust attribute contract:
 
a) Navigate to SP Connection > WS-Trust STS > Token Creation - Attribute Contract.

b) Add the following attributes and corresponding attribute namespaces:
 
  Attribute name  Attribute Namespace
 accounttype http://schemas.microsoft.com/ws/2012/01
 onpremobjectguid http://schemas.microsoft.com/identity/claims
 primarysid http://schemas.microsoft.com/ws/2008/06/identity/claims 
 SAML_NAME_FORMAT  http://schemas.microsoft.com/claims

c) Click Next twice and then click the Kerberos Token Processor instance.


6. Extend LDAP search for the Kerberos Token Processor:

a) Go to the Attribute Sources & User Lookup tab and then click on the LDAP data store instance.

b) Click on the LDAP Directory Search tab and add objectSid attribute to return from search.

Note: Make sure that Base DN and Search Scope LDAP settings cover both a container with Office 365 users and a container where the Computer AD objects of the devices intended for Azure AD registration are located.

c) Click Next and set Attribute Encoding Type to SID for the OBJECTSID attribute under the LDAP Binary Attribute Encoding Types tab.

User-added image


d) Click Next and confirm that LDAP Filter includes the following:


|(sAMAccountName=${username})(userPrincipalName=${username})


7. Map Attribute Contract to values of the Kerberos Token Processor instance:
 
a) Click Done and then click Next until you get to the Attribute Contract Fulfillment section of your Kerberos Token Processor instance.

b) Populate missing fields according to the following table: ​


 
 Attribute Contract  Source  Value
 ImmutableID LDAP objectGUID
 TOKEN_SUBJECT  LDAP objectGUID
 UPN Token principle
 accounttype Text DJ
 onpremobjectguid  LDAP objectGUID
 primarysid LDAP objectSid
 SAML_NAME_FORMAT   Text urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

c) Click Done.


8. Map Attribute Contract to values of the Username Token Processor instance:
 
a) Click the Username Token Processor instance and navigate to the Attribute Contract Fulfillment tab. 

b) Populate missing fields according to the table below: 


 
 Attribute Contract  Source  Value 
 ImmutableID  LDAP objectGUID
 TOKEN_SUBJECT  LDAP objectGUID
 UPN  LDAP userPrincipalName
 accounttype  Text N/A
 onpremobjectguid  LDAP objectGUID
 primarysid  Text N/A
 SAML_NAME_FORMAT  Text urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

c) Click Save.
 


Control deployment and rollout


Automatic device registration rollout and deployment for the Windows current devices can be controlled through a Group Policy.

Configuration steps can be found in the Microsoft article How to control the hybrid Azure AD join of your devices.

 
When you have completed all the required steps listed above, domain-joined Windows devices are ready to automatically register with Azure AD.
All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016 (or later) automatically register with Azure AD at device restart or user sign-in.
New devices register with Azure AD when the device restarts after the domain join operation completes.


 

Device Registration status verification


When the Group Policy is applied and user signs in to the Windows 10 device, the automatic device registration process happens in the background.
There are several options to check the device status and verify the successful registration in Azure AD.


 
1. Checking the Windows device:

Run the following command in a Windows PowerShell prompt on the Windows 10 device. 

dsregcmd.exe /status

A successful device registration screen should look like the screenshot below.

Confirm that the following fields have corresponding values:
 
AzureAdJoined : YES
DomainJoined : YES
WorkplaceJoined :NO
WamDefaultSet : YES
AzureADPrt :YES
 
User-added image
 

If you see something different, this means that the device registration process failed at some point. For troubleshooting tips see the following Microsoft KB Article:

Troubleshooting hybrid Azure Active Directory joined Windows 10 and Windows Server 2016 devices.


2. Checking Azure AD:
 
There are two ways of checking device registration status in Azure AD.
 
 
2.1 Using the Microsoft Azure portal:
 
a) Open the Microsoft Azure portal.

b) Navigate to Azure Active Directory > Devices.
 
 
2.2 Using PowerShell commands:
 
a) Open the latest version of the Microsoft Azure Active Directory Module for Windows PowerShell.

b) Connect to your Azure AD tenant by running the following command:


Connect-MsolService

c) Enter your Azure AD administrator account credentials when prompted.
 
d) Type one the following commands:
 
  • To see all registered devices:
Get-MsolDevice -All
  • To see a specific device using DeviceID (from the screenshot above as an example).
Get-MsolDevice -DeviceID "<device_id_value>"

 

Example:
 
User-added image

 
Category:
Integrations , 
KB or other URL: