Contents

Device Identities Documentation

Overview
What is a device identity?
What is enterprise state roaming?
Tutorials
Configure hybrid Azure AD join for managed domains
Configure hybrid Azure AD join for federated domains
Configure hybrid Azure AD join manually
Configure Azure AD join during Windows 10 first-run experience
Concepts
Azure AD registered devices
Azure AD joined devices
Hybrid Azure AD joined devices
SSO to on-premises resources
Primary Refresh Tokens
Azure-managed workstations
How-to guides
Plan your Azure AD device deployment
Plan your Azure AD join implementation
Assign local admins to Azure AD joined devices
Plan your hybrid Azure AD join implementation
Controlled validation of hybrid Azure AD join
Manage device identities
Manage stale devices
Enable enterprise state roaming
Windows Azure VMs and Azure AD
Virtual desktop infrastructure
Deploy Azure-managed workstations
Troubleshoot device identities
 Troubleshoot hybrid Azure AD joined Windows current devices
Troubleshoot using dsregcmd
Troubleshoot hybrid Azure AD joined down level Windows devices
Troubleshoot enterprise state roaming
Frequently asked questions
FAQs
Enable enterprise state FAQs
Reference
Enforce TLS 1.2
Enterprise state roaming GPO settings
Enterprise state roaming Windows settings
Graph APIs
Device identity API
Resources
Azure feedback forum
Microsoft Q&A question page
Pricing
Service updates
Stack Overflow
Videos
 What is a device identity?
9/7/2020 • 3 minutes to read • Edit Online

With the proliferation of devices of all shapes and sizes and the Bring Your Own Device (BYOD) concept, IT
professionals are faced with two somewhat opposing goals:
Allow end users to be productive wherever and whenever
Protect the organization's assets
To protect these assets, IT staff need to first manage the device identities. IT staff can build on the device identity
with tools like Microsoft Intune to ensure standards for security and compliance are met. Azure Active Directory
(Azure AD) enables single sign-on to devices, apps, and services from anywhere through these devices.
Your users get access to your organization's assets they need.
Your IT staff get the controls they need to secure your organization.
Device identity management is the foundation for device-based Conditional Access. With device-based
Conditional Access policies, you can ensure that access to resources in your environment is only possible with
managed devices.

Getting devices in Azure AD

To get a device in Azure AD, you have multiple options:
Azure AD registered
Devices that are Azure AD registered are typically personally owned or mobile devices, and are signed
in with a personal Microsoft account or another local account.
Windows 10
iOS
Android
MacOS
Azure AD joined
Devices that are Azure AD joined are owned by an organization, and are signed in with an Azure AD
account belonging to that organization. They exist only in the cloud.
Windows 10
Windows Server 2019 Virtual Machines running in Azure (Server core is not supported)
Hybrid Azure AD joined
Devices that are hybrid Azure AD joined are owned by an organization, and are signed in with an
Active Directory Domain Services account belonging to that organization. They exist in the cloud and
on-premises.
Windows 7, 8.1, or 10
Windows Server 2008 or newer
 NOTE
A hybrid state refers to more than just the state of a device. For a hybrid state to be valid, a valid Azure AD user also is
required.

Device management
Devices in Azure AD can be managed using Mobile Device Management (MDM) tools like Microsoft Intune,
Microsoft Endpoint Configuration Manager, Group Policy (hybrid Azure AD join), Mobile Application
Management (MAM) tools, or other third-party tools.

Resource access
Registering and joining devices to Azure AD gives your users Seamless Sign-on (SSO) to cloud resources. This
process also allows administrators the ability to apply Conditional Access policies to resources based on the
device they are accessed from.

NOTE
Device-based Conditional Access policies require either hybrid Azure AD joined devices or compliant Azure AD joined or
Azure AD registered devices.

The primary refresh token (PRT) contains information about the device and is required for SSO. If you have a
device-based Conditional Access policy set on an application, without the PRT, access is denied. Hybrid
Conditional Access policies require a hybrid state device and a valid user who is signed in.
Devices that are Azure AD joined or hybrid Azure AD joined benefit from SSO to your organization's on-premises
resources as well as cloud resources. More information can be found in the article, How SSO to on-premises
resources works on Azure AD joined devices.

Device security
Azure AD registered devices utilize an account managed by the end user, this account is either a Microsoft
account or another locally managed credential secured with one or more of the following.
 Password
PIN
Pattern
Windows Hello
Azure AD joined or hybrid Azure AD joined devices utilize an organizational account in Azure AD
secured with one or more of the following.
Password
Windows Hello for Business

Provisioning
Getting devices in to Azure AD can be done in a self-service manner or a controlled provisioning process by
administrators.

Summary
With device identity management in Azure AD, you can:
Simplify the process of bringing and managing devices in Azure AD
Provide your users with an easy to use access to your organization's cloud-based resources

License requirements
Using this feature requires an Azure AD Premium P1 license. To find the right license for your requirements,
see Comparing generally available features of the Free, Basic, and Premium editions.

Next steps
Learn more about Azure AD registered devices
Learn more about Azure AD joined devices
Learn more about hybrid Azure AD joined devices
To get an overview of how to manage device identities in the Azure portal, see Managing device identities
using the Azure portal.
To learn more about device-based Conditional Access, see Configure Azure Active Directory device-based
Conditional Access policies.
 What is enterprise state roaming?
2/13/2020 • 2 minutes to read • Edit Online

With Windows 10, Azure Active Directory (Azure AD) users gain the ability to securely synchronize their user
settings and application settings data to the cloud. Enterprise State Roaming provides users with a unified
experience across their Windows devices and reduces the time needed for configuring a new device. Enterprise
State Roaming operates similar to the standard consumer settings sync that was first introduced in Windows 8.
Additionally, Enterprise State Roaming offers:
Separation of corporate and consumer data – Organizations are in control of their data, and there is no
mixing of corporate data in a consumer cloud account or consumer data in an enterprise cloud account.
Enhanced security – Data is automatically encrypted before leaving the user’s Windows 10 device by using
Azure Rights Management (Azure RMS), and data stays encrypted at rest in the cloud. All content stays
encrypted at rest in the cloud, except for the namespaces, like settings names and Windows app names.
Better management and monitoring – Provides control and visibility over who syncs settings in your
organization and on which devices through the Azure AD portal integration.
Enterprise State Roaming is available in multiple Azure regions. You can find the updated list of available regions
on the Azure Services by Regions page under Azure Active Directory.

A RT IC L E DESC RIP T IO N

Enable Enterprise State Roaming in Azure Active Directory Enterprise State Roaming is available to any organization with
a Premium Azure Active Directory (Azure AD) subscription.
For more information on how to get an Azure AD
subscription, see the Azure AD product page.

Settings and data roaming FAQ This article answers some questions IT administrators might
have about settings and app data sync.

Group policy and MDM settings for settings sync Windows 10 provides Group Policy and mobile device
management (MDM) policy settings to limit settings sync.

Windows 10 roaming settings reference A list of settings that will be roamed and/or backed-up in
Windows 10.

Troubleshooting This article goes through some basic steps for

troubleshooting, and contains a list of known issues.

Next steps
For information about enabling enterprise state roaming, see enable enterprise state roaming.
 Tutorial: Configure hybrid Azure Active Directory join
for managed domains
9/7/2020 • 7 minutes to read • Edit Online

In this tutorial, you learn how to configure hybrid Azure Active Directory (Azure AD) join for Active Directory
domain-joined devices. This method supports a managed environment that includes both on-premises Active
Directory and Azure AD.
Like a user in your organization, a device is a core identity you want to protect. You can use a device's identity to
protect your resources at any time and from any location. You can accomplish this goal by managing device
identities in Azure AD. Use one of the following methods:
Azure AD join
Hybrid Azure AD join
Azure AD registration
This article focuses on hybrid Azure AD join.
Bringing your devices to Azure AD maximizes user productivity through single sign-on (SSO) across your cloud
and on-premises resources. You can secure access to your cloud and on-premises resources with Conditional
Access at the same time.
You can deploy a managed environment by using password hash sync (PHS) or pass-through authentication (PTA)
with seamless single sign-on. These scenarios don't require you to configure a federation server for authentication.
In this tutorial, you learn how to:
Configure hybrid Azure AD join
Enable Windows down-level devices
Verify joined devices
Troubleshoot

Prerequisites
The Azure AD Connect (1.1.819.0 or later)
The credentials of a global administrator for your Azure AD tenant
The enterprise administrator credentials for each of the forests
Familiarize yourself with these articles:
What is a device identity?
How To: Plan your hybrid Azure Active Directory join implementation
Controlled validation of hybrid Azure AD join

NOTE
Azure AD doesn't support smartcards or certificates in managed domains.

Verify that Azure AD Connect has synced the computer objects of the devices you want to be hybrid Azure AD
joined to Azure AD. If the computer objects belong to specific organizational units (OUs), configure the OUs to sync
in Azure AD Connect. To learn more about how to sync computer objects by using Azure AD Connect, see
Organizational unit–based filtering.
Beginning with version 1.1.819.0, Azure AD Connect includes a wizard to configure hybrid Azure AD join. The
wizard significantly simplifies the configuration process. The wizard configures the service connection points
(SCPs) for device registration.
The configuration steps in this article are based on using the wizard in Azure AD Connect.
Hybrid Azure AD join requires devices to have access to the following Microsoft resources from inside your
organization's network:
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
https://device.login.microsoftonline.com
https://autologon.microsoftazuread-sso.com (If you use or plan to use seamless SSO)

WARNING
If your organization uses proxy servers that intercept SSL traffic for scenarios like data loss prevention or Azure AD tenant
restrictions, ensure that traffic to 'https://device.login.microsoftonline.com' is excluded from TLS break-and-inspect. Failure to
exclude 'https://device.login.microsoftonline.com' may cause interference with client certificate authentication, causing issues
with device registration and device-based Conditional Access.

If your organization requires access to the internet via an outbound proxy, you can use implementing Web Proxy
Auto-Discovery (WPAD) to enable Windows 10 computers for device registration with Azure AD. To address issues
configuring and managing WPAD, see Troubleshooting Automatic Detection. In Windows 10 devices prior to 1709
update, WPAD is the only available option to configure a proxy to work with Hybrid Azure AD join.
If you don't use WPAD, you can configure WinHTTP proxy settings on your computer beginning with Windows 10
1709. For more information, see WinHTTP Proxy Settings deployed by GPO.

NOTE
If you configure proxy settings on your computer by using WinHTTP settings, any computers that can't connect to the
configured proxy will fail to connect to the internet.

If your organization requires access to the internet via an authenticated outbound proxy, make sure that your
Windows 10 computers can successfully authenticate to the outbound proxy. Because Windows 10 computers run
device registration by using machine context, configure outbound proxy authentication by using machine context.
Follow up with your outbound proxy provider on the configuration requirements.
Verify the device can access the above Microsoft resources under the system account by using the Test Device
Registration Connectivity script.

Configure hybrid Azure AD join

To configure a hybrid Azure AD join by using Azure AD Connect:
1. Start Azure AD Connect, and then select Configure .
2. In Additional tasks , select Configure device options , and then select Next .

3. In Over view , select Next .

4. In Connect to Azure AD , enter the credentials of a global administrator for your Azure AD tenant.

5. In Device options , select Configure Hybrid Azure AD join , and then select Next .
6. In SCP configuration , for each forest where you want Azure AD Connect to configure the SCP, complete
the following steps, and then select Next .
a. Select the Forest .
b. Select an Authentication Ser vice .
c. Select Add to enter the enterprise administrator credentials.

7. In Device operating systems , select the operating systems that devices in your Active Directory
environment use, and then select Next .
8. In Ready to configure , select Configure .

9. In Configuration complete , select Exit .

Enable Windows down-level devices
If some of your domain-joined devices are Windows down-level devices, you must:
Configure the local intranet settings for device registration
Configure seamless SSO
Install Microsoft Workplace Join for Windows down-level computers

NOTE
Windows 7 support ended on January 14, 2020. For more information, see Windows 7 support ended.

Configure the local intranet settings for device registration

To complete hybrid Azure AD join of your Windows down-level devices and to avoid certificate prompts when
devices authenticate to Azure AD, you can push a policy to your domain-joined devices to add the following URLs
to the local intranet zone in Internet Explorer:
https://device.login.microsoftonline.com
https://autologon.microsoftazuread-sso.com

You also must enable Allow updates to status bar via script in the user's local intranet zone.
Configure seamless SSO
To complete hybrid Azure AD join of your Windows down-level devices in a managed domain that uses password
hash sync or pass-through authentication as your Azure AD cloud authentication method, you must also configure
seamless SSO.
Install Microsoft Workplace Join for Windows down-level computers
To register Windows down-level devices, organizations must install Microsoft Workplace Join for non-Windows 10
computers. Microsoft Workplace Join for non-Windows 10 computers is available in the Microsoft Download
Center.
You can deploy the package by using a software distribution system likeMicrosoft Endpoint Configuration
Manager. The package supports the standard silent installation options with the quiet parameter. The current
version of Configuration Manager offers benefits over earlier versions, like the ability to track completed
registrations.
The installer creates a scheduled task on the system that runs in the user context. The task is triggered when the
user signs in to Windows. The task silently joins the device with Azure AD by using the user credentials after it
authenticates with Azure AD.

Verify the registration

Here are 3 ways to locate and verify the device state:
Locally on the device
1. Open Windows PowerShell.
2. Enter dsregcmd /status .
3. Verify that both AzureAdJoined and DomainJoined are set to YES .
4. You can use the DeviceId and compare the status on the service using either the Azure portal or PowerShell.
Using the Azure portal
1. Go to the devices page using a direct link.
2. Information on how to locate a device can be found in How to manage device identities using the Azure portal.
3. If the Registered column says Pending , then Hybrid Azure AD Join has not completed.
4. If the Registered column contains a date/time , then Hybrid Azure AD Join has completed.
Using PowerShell
Verify the device registration state in your Azure tenant by using Get-MsolDevice . This cmdlet is in the Azure
Active Directory PowerShell module.
When you use the Get-MSolDevice cmdlet to check the service details:
An object with the device ID that matches the ID on the Windows client must exist.
The value for DeviceTrustType is Domain Joined . This setting is equivalent to the Hybrid Azure AD joined
state on the Devices page in the Azure AD portal.
For devices that are used in Conditional Access, the value for Enabled is True and DeviceTrustLevel is
Managed .
1. Open Windows PowerShell as an administrator.
2. Enter Connect-MsolService to connect to your Azure tenant.
Count all Hybrid Azure AD joined devices (excluding Pending state)

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

Count all Hybrid Azure AD joined devices with Pending state

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-

not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

List all Hybrid Azure AD joined devices

Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}
List all Hybrid Azure AD joined devices with Pending state

Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-

not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}

List details of a single device:

1. Enter get-msoldevice -deviceId <deviceId> (This is the DeviceId obtained locally on the device).
2. Verify that Enabled is set to True .

Troubleshoot your implementation

If you experience issues completing hybrid Azure AD join for domain-joined Windows devices, see:
Troubleshooting devices using dsregcmd command
Troubleshooting hybrid Azure Active Directory joined devices
Troubleshooting hybrid Azure Active Directory joined down-level devices

Next steps
Advance to the next article to learn how to manage device identities by using the Azure portal.
Manage device identities
 Tutorial: Configure hybrid Azure Active Directory join
for federated domains
9/7/2020 • 8 minutes to read • Edit Online

Like a user in your organization, a device is a core identity you want to protect. You can use a device's identity to
protect your resources at any time and from any location. You can accomplish this goal by bringing device
identities and managing them in Azure Active Directory (Azure AD) by using one of the following methods:
Azure AD join
Hybrid Azure AD join
Azure AD registration
Bringing your devices to Azure AD maximizes user productivity through single sign-on (SSO) across your cloud
and on-premises resources. You can secure access to your cloud and on-premises resources with Conditional
Access at the same time.
A federated environment should have an identity provider that supports the following requirements. If you have a
federated environment using Active Directory Federation Services (AD FS), then the below requirements are
already supported.
WIAORMULTIAUTHN claim: This claim is required to do hybrid Azure AD join for Windows down-level
devices.
WS-Trust protocol: This protocol is required to authenticate Windows current hybrid Azure AD joined devices
with Azure AD. When you're using AD FS, you need to enable the following WS-Trust endpoints:
/adfs/services/trust/2005/windowstransport /adfs/services/trust/13/windowstransport
/adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed
/adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed

WARNING
Both adfs/ser vices/trust/2005/windowstranspor t and adfs/ser vices/trust/13/windowstranspor t should be
enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web
Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see Disable WS-Trust Windows endpoints
on the proxy. You can see what endpoints are enabled through the AD FS management console under Ser vice >
Endpoints .

In this tutorial, you learn how to configure hybrid Azure AD join for Active Directory domain-joined computers
devices in a federated environment by using AD FS.
You learn how to:
Configure hybrid Azure AD join
Enable Windows downlevel devices
Verify the registration
Troubleshoot

Prerequisites
This tutorial assumes that you're familiar with these articles:
 What is a device identity?
How to plan your hybrid Azure AD join implementation
How to do controlled validation of hybrid Azure AD join
To configure the scenario in this tutorial, you need:
Windows Server 2012 R2 with AD FS
Azure AD Connect version 1.1.819.0 or later
Beginning with version 1.1.819.0, Azure AD Connect includes a wizard that you can use to configure hybrid Azure
AD join. The wizard significantly simplifies the configuration process. The related wizard:
Configures the service connection points (SCPs) for device registration
Backs up your existing Azure AD relying party trust
Updates the claim rules in your Azure AD trust
The configuration steps in this article are based on using the Azure AD Connect wizard. If you have an earlier
version of Azure AD Connect installed, you must upgrade it to 1.1.819 or later to use the wizard. If installing the
latest version of Azure AD Connect isn't an option for you, see how to manually configure hybrid Azure AD join.
Hybrid Azure AD join requires devices to have access to the following Microsoft resources from inside your
organization's network:
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
https://device.login.microsoftonline.com
Your organization's Security Token Service (STS) (For federated domains)
https://autologon.microsoftazuread-sso.com (If you use or plan to use seamless SSO)

WARNING
If your organization uses proxy servers that intercept SSL traffic for scenarios like data loss prevention or Azure AD tenant
restrictions, ensure that traffic to 'https://device.login.microsoftonline.com' is excluded from TLS break-and-inspect. Failure to
exclude 'https://device.login.microsoftonline.com' may cause interference with client certificate authentication, causing issues
with device registration and device-based Conditional Access.

Beginning with Windows 10 1803, if the instantaneous hybrid Azure AD join for a federated environment by using
AD FS fails, we rely on Azure AD Connect to sync the computer object in Azure AD that's subsequently used to
complete the device registration for hybrid Azure AD join. Verify that Azure AD Connect has synced the computer
objects of the devices you want to be hybrid Azure AD joined to Azure AD. If the computer objects belong to
specific organizational units (OUs), you must also configure the OUs to sync in Azure AD Connect. To learn more
about how to sync computer objects by using Azure AD Connect, see Configure filtering by using Azure AD
Connect.
If your organization requires access to the internet via an outbound proxy, Microsoft recommends implementing
Web Proxy Auto-Discovery (WPAD) to enable Windows 10 computers for device registration with Azure AD. If you
encounter issues configuring and managing WPAD, see Troubleshoot automatic detection.
If you don't use WPAD and want to configure proxy settings on your computer, you can do so beginning with
Windows 10 1709. For more information, see Configure WinHTTP settings by using a group policy object (GPO).
 NOTE
If you configure proxy settings on your computer by using WinHTTP settings, any computers that can't connect to the
configured proxy will fail to connect to the internet.

If your organization requires access to the internet via an authenticated outbound proxy, you must make sure that
your Windows 10 computers can successfully authenticate to the outbound proxy. Because Windows 10
computers run device registration by using machine context, you must configure outbound proxy authentication
by using machine context. Follow up with your outbound proxy provider on the configuration requirements.
To verify if the device is able to access the above Microsoft resources under the system account, you can use Test
Device Registration Connectivity script.

Configure hybrid Azure AD join

To configure a hybrid Azure AD join by using Azure AD Connect, you need:
The credentials of a global administrator for your Azure AD tenant
The enterprise administrator credentials for each of the forests
The credentials of your AD FS administrator
To configure a hybrid Azure AD join by using Azure AD Connect :
1. Start Azure AD Connect, and then select Configure .

2. On the Additional tasks page, select Configure device options , and then select Next .
3. On the Over view page, select Next .

4. On the Connect to Azure AD page, enter the credentials of a global administrator for your Azure AD
tenant, and then select Next .
5. On the Device options page, select Configure Hybrid Azure AD join , and then select Next .

6. On the SCP page, complete the following steps, and then select Next :
 a. Select the forest.
b. Select the authentication service. You must select AD FS ser ver unless your organization has
exclusively Windows 10 clients and you have configured computer/device sync, or your organization
uses seamless SSO.
c. Select Add to enter the enterprise administrator credentials.
7. On the Device operating systems page, select the operating systems that the devices in your Active
Directory environment use, and then select Next .
 8. On the Federation configuration page, enter the credentials of your AD FS administrator, and then select
Next .

9. On the Ready to configure page, select Configure .

10. On the Configuration complete page, select Exit .

Enable Windows downlevel devices
If some of your domain-joined devices are Windows downlevel devices, you must:
Configure the local intranet settings for device registration
Install Microsoft Workplace Join for Windows downlevel computers

NOTE
Windows 7 support ended on January 14, 2020. For more information, Support for Windows 7 has ended.

Configure the local intranet settings for device registration

To successfully complete hybrid Azure AD join of your Windows downlevel devices and to avoid certificate
prompts when devices authenticate to Azure AD, you can push a policy to your domain-joined devices to add the
following URLs to the local intranet zone in Internet Explorer:
https://device.login.microsoftonline.com
Your organization's STS (For federated domains)
https://autologon.microsoftazuread-sso.com (For seamless SSO)

You also must enable Allow updates to status bar via script in the user’s local intranet zone.
Install Microsoft Workplace Join for Windows downlevel computers
To register Windows downlevel devices, organizations must install Microsoft Workplace Join for non-Windows 10
computers. Microsoft Workplace Join for non-Windows 10 computers is available in the Microsoft Download
Center.
You can deploy the package by using a software distribution system likeMicrosoft Endpoint Configuration
Manager. The package supports the standard silent installation options with the quiet parameter. The current
branch of Configuration Manager offers benefits over earlier versions, like the ability to track completed
registrations.
The installer creates a scheduled task on the system that runs in the user context. The task is triggered when the
user signs in to Windows. The task silently joins the device with Azure AD by using the user credentials after it
authenticates with Azure AD.

Verify the registration

Here are 3 ways to locate and verify the device state:
Locally on the device
1. Open Windows PowerShell.
2. Enter dsregcmd /status .
3. Verify that both AzureAdJoined and DomainJoined are set to YES .
4. You can use the DeviceId and compare the status on the service using either the Azure portal or PowerShell.
Using the Azure portal
1. Go to the devices page using a direct link.
2. Information on how to locate a device can be found in How to manage device identities using the Azure portal.
3. If the Registered column says Pending , then Hybrid Azure AD Join has not completed. In federated
environments, this can happen only if it failed to register and AAD connect is configured to sync the devices.
4. If the Registered column contains a date/time , then Hybrid Azure AD Join has completed.
Using PowerShell
Verify the device registration state in your Azure tenant by using Get-MsolDevice . This cmdlet is in the Azure
Active Directory PowerShell module.
When you use the Get-MSolDevice cmdlet to check the service details:
An object with the device ID that matches the ID on the Windows client must exist.
The value for DeviceTrustType is Domain Joined . This setting is equivalent to the Hybrid Azure AD joined
state on the Devices page in the Azure AD portal.
For devices that are used in Conditional Access, the value for Enabled is True and DeviceTrustLevel is
Managed .
1. Open Windows PowerShell as an administrator.
2. Enter Connect-MsolService to connect to your Azure tenant.
Count all Hybrid Azure AD joined devices (excluding Pending state)

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

Count all Hybrid Azure AD joined devices with Pending state

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-

not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

List all Hybrid Azure AD joined devices

Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}

List all Hybrid Azure AD joined devices with Pending state

 Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-
not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}

List details of a single device:

1. Enter get-msoldevice -deviceId <deviceId> (This is the DeviceId obtained locally on the device).
2. Verify that Enabled is set to True .

Troubleshoot your implementation

If you experience issues with completing hybrid Azure AD join for domain-joined Windows devices, see:
Troubleshooting devices using dsregcmd command
Troubleshoot hybrid Azure AD join for Windows current devices
Troubleshoot hybrid Azure AD join for Windows downlevel devices

Next steps
Learn how to manage device identities by using the Azure portal.
 Tutorial: Configure hybrid Azure Active Directory
joined devices manually
9/7/2020 • 17 minutes to read • Edit Online

With device management in Azure Active Directory (Azure AD), you can ensure that users are accessing your
resources from devices that meet your standards for security and compliance. For more information, see
Introduction to device management in Azure Active Directory.

TIP
If using Azure AD Connect is an option for you, see the related tutorials for managed or federated domains. By using Azure
AD Connect, you can significantly simplify the configuration of hybrid Azure AD join.

If you have an on-premises Active Directory environment and you want to join your domain-joined devices to
Azure AD, you can accomplish this by configuring hybrid Azure AD joined devices. In this tutorial, you learn how to:
Manually configure hybrid Azure AD join
Configure a service connection point
Set up issuance of claims
Enable Windows down-level devices
Verify joined devices
Troubleshoot your implementation

Prerequisites
This tutorial assumes that you're familiar with:
Introduction to device management in Azure Active Directory
Plan your hybrid Azure Active Directory join implementation
Control the hybrid Azure AD join of your devices
Before you start enabling hybrid Azure AD joined devices in your organization, make sure that:
You're running an up-to-date version of Azure AD Connect.
Azure AD Connect has synchronized the computer objects of the devices you want to be hybrid Azure AD joined
to Azure AD. If the computer objects belong to specific organizational units (OUs), these OUs need to be
configured for synchronization in Azure AD Connect as well.
Azure AD Connect:
Keeps the association between the computer account in your on-premises Active Directory instance and the
device object in Azure AD.
Enables other device-related features, like Windows Hello for Business.
Make sure that the following URLs are accessible from computers inside your organization's network for
registration of computers to Azure AD:
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
 https://device.login.microsoftonline.com
Your organization's STS (for federated domains), which should be included in the user's local intranet settings

WARNING
If your organization uses proxy servers that intercept SSL traffic for scenarios like data loss prevention or Azure AD tenant
restrictions, ensure that traffic to 'https://device.login.microsoftonline.com' is excluded from TLS break-and-inspect. Failure to
exclude 'https://device.login.microsoftonline.com' may cause interference with client certificate authentication, causing issues
with device registration and device-based Conditional Access.

If your organization plans to use Seamless SSO, the following URL needs to be reachable from the computers
inside your organization. It must also be added to the user's local intranet zone.
https://autologon.microsoftazuread-sso.com

Also, the following setting should be enabled in the user's intranet zone: "Allow status bar updates via script."
If your organization uses managed (non-federated) setup with on-premises Active Directory and does not use
Active Directory Federation Services (AD FS) to federate with Azure AD, then hybrid Azure AD join on Windows 10
relies on the computer objects in Active Directory to be synced to Azure AD. Make sure that any OUs that contain
the computer objects that need to be hybrid Azure AD joined are enabled for sync in the Azure AD Connect sync
configuration.
For Windows 10 devices on version 1703 or earlier, if your organization requires access to the internet via an
outbound proxy, you must implement Web Proxy Auto-Discovery (WPAD) to enable Windows 10 computers to
register to Azure AD.
Beginning with Windows 10 1803, even if a hybrid Azure AD join attempt by a device in a federated domain
through AD FS fails, and if Azure AD Connect is configured to sync the computer/device objects to Azure AD, the
device will try to complete the hybrid Azure AD join by using the synced computer/device.
To verify if the device is able to access the above Microsoft resources under the system account, you can use Test
Device Registration Connectivity script.

Verify configuration steps

You can configure hybrid Azure AD joined devices for various types of Windows device platforms. This topic
includes the required steps for all typical configuration scenarios.
Use the following table to get an overview of the steps that are required for your scenario:

W IN DO W S C URREN T A N D W IN DO W S C URREN T A N D
ST EP S PA SSW O RD H A SH SY N C F EDERAT IO N W IN DO W S DO W N - L EVEL

Configure service
connection point

Set up issuance of claims

Enable non-Windows 10
devices

Verify joined devices

Configure a service connection point

Your devices use a service connection point (SCP) object during the registration to discover Azure AD tenant
information. In your on-premises Active Directory instance, the SCP object for the hybrid Azure AD joined devices
must exist in the configuration naming context partition of the computer's forest. There is only one configuration
naming context per forest. In a multi-forest Active Directory configuration, the service connection point must exist
in all forests that contain domain-joined computers.
You can use the Get-ADRootDSE cmdlet to retrieve the configuration naming context of your forest.
For a forest with the Active Directory domain name fabrikam.com, the configuration naming context is:
CN=Configuration,DC=fabrikam,DC=com

In your forest, the SCP object for the auto-registration of domain-joined devices is located at:
CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration
Naming Context]

Depending on how you have deployed Azure AD Connect, the SCP object might have already been configured. You
can verify the existence of the object and retrieve the discovery values by using the following Windows PowerShell
script:

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration

Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

The $scp.Keywords output shows the Azure AD tenant information. Here's an example:

azureADName:microsoft.com
azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47

If the service connection point does not exist, you can create it by running the
Initialize-ADSyncDomainJoinedComputerSync cmdlet on your Azure AD Connect server. Enterprise admin credentials
are required to run this cmdlet.
The cmdlet:
Creates the service connection point in the Active Directory forest that Azure AD Connect is connected to.
Requires you to specify the AdConnectorAccount parameter. This account is configured as the Active Directory
connector account in Azure AD Connect.
The following script shows an example for using the cmdlet. In this script, $aadAdminCred = Get-Credential requires
you to type a user name. You need to provide the user name in the user principal name (UPN) format (
[email protected] ).

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;

The Initialize-ADSyncDomainJoinedComputerSync cmdlet:

Uses the Active Directory PowerShell module and Azure Active Directory Domain Services (Azure AD DS) tools.
These tools rely on Active Directory Web Services running on a domain controller. Active Directory Web
 Services is supported on domain controllers running Windows Server 2008 R2 and later.
Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this
link.
If the AD DS tools are not installed, Initialize-ADSyncDomainJoinedComputerSync will fail. You can install the AD
DS tools through Server Manager under Features > Remote Ser ver Administration Tools > Role
Administration Tools .
For domain controllers running Windows Server 2008 or earlier versions, use the following script to create the
service connection point. In a multi-forest configuration, use the following script to create the service connection
point in each forest where computers exist.

$verifiedDomain = "contoso.com" # Replace this with any of your verified domain names in Azure AD
$tenantID = "72f988bf-86f1-41af-91ab-2d7cd011db47" # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com" # Replace this with your Active Directory
configuration naming context

$de = New-Object System.DirectoryServices.DirectoryEntry

$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deDRC.CommitChanges()

$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")

$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)

$deSCP.CommitChanges()

In the preceding script, $verifiedDomain = "contoso.com" is a placeholder. Replace it with one of your verified
domain names in Azure AD. You have to own the domain before you can use it.
For more information about verified domain names, see Add a custom domain name to Azure Active Directory.
To get a list of your verified company domains, you can use the Get-AzureADDomain cmdlet.

Set up issuance of claims

In a federated Azure AD configuration, devices rely on AD FS or an on-premises federation service from a
Microsoft partner to authenticate to Azure AD. Devices authenticate to get an access token to register against the
Azure Active Directory Device Registration Service (Azure DRS).
Windows current devices authenticate by using Integrated Windows Authentication to an active WS-Trust endpoint
(either 1.3 or 2005 versions) hosted by the on-premises federation service.
When you're using AD FS, you need to enable the following WS-Trust endpoints
/adfs/services/trust/2005/windowstransport
/adfs/services/trust/13/windowstransport
/adfs/services/trust/2005/usernamemixed
/adfs/services/trust/13/usernamemixed
/adfs/services/trust/2005/certificatemixed
/adfs/services/trust/13/certificatemixed
 WARNING
Both adfs/ser vices/trust/2005/windowstranspor t and adfs/ser vices/trust/13/windowstranspor t should be
enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web
Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see Disable WS-Trust Windows endpoints
on the proxy. You can see what endpoints are enabled through the AD FS management console under Ser vice >
Endpoints .

NOTE
If you don’t have AD FS as your on-premises federation service, follow the instructions from your vendor to make sure they
support WS-Trust 1.3 or 2005 endpoints and that these are published through the Metadata Exchange file (MEX).

For device registration to finish, the following claims must exist in the token that Azure DRS receives. Azure DRS
will create a device object in Azure AD with some of this information. Azure AD Connect then uses this information
to associate the newly created device object with the computer account on-premises.
http://schemas.microsoft.com/ws/2012/01/accounttype
http://schemas.microsoft.com/identity/claims/onpremobjectguid
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

If you have more than one verified domain name, you need to provide the following claim for computers:
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid

If you're already issuing an ImmutableID claim (for example, using mS-DS-ConsistencyGuid or another attribute as
the source value for the ImmutableID), you need to provide one corresponding claim for computers:
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

In the following sections, you find information about:

The values that each claim should have.
What a definition would look like in AD FS.
The definition helps you to verify whether the values are present or if you need to create them.

NOTE
If you don’t use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate
configuration to issue these claims.

Issue account type claim

The http://schemas.microsoft.com/ws/2012/01/accounttype claim must contain a value of DJ , which identifies the
device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
 @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"
);

Issue objectGUID of the computer account on-premises

The http://schemas.microsoft.com/identity/claims/onpremobjectguid claim must contain the objectGUID value of
the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:

@RuleName = "Issue object GUID for domain-joined computers"

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
);

Issue objectSID of the computer account on-premises

The http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid claim must contain the objectSid value
of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:

@RuleName = "Issue objectSID for domain-joined computers"

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);

Issue issuerID for the computer when multiple verified domain names are in Azure AD
The http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid claim must contain the Uniform Resource
Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or
partner) issuing the token. In AD FS, you can add issuance transform rules that look like the following ones in that
specific order, after the preceding ones. Note that one rule to explicitly issue the rule for users is necessary. In the
following rules, a first rule that identifies user versus computer authentication is added.
 @RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);

@RuleName = "Issue issuerID 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/2008/06/identity/claims/issuerid",
Value = "http://<verified-domain-name>/adfs/services/trust/"
);

In the preceding claim, <verified-domain-name> is a placeholder. Replace it with one of your verified domain names
in Azure AD. For example, use Value = "http://contoso.com/adfs/services/trust/" .
For more information about verified domain names, see Add a custom domain name to Azure Active Directory.
To get a list of your verified company domains, you can use the Get-MsolDomain cmdlet.

Issue ImmutableID for the computer when one for users exists (for example, using mS -DS -ConsistencyGuid as
the source for ImmutableID)
The http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID claim must contain a valid value for
computers. In AD FS, you can create an issuance transform rule as follows:
 @RuleName = "Issue ImmutableID for computers"
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/LiveID/Federation/2008/05/ImmutableID"),
query = ";objectguid;{0}",
param = c2.Value
);

Helper script to create the AD FS issuance transform rules

The following script helps you with the creation of the issuance transform rules described earlier.

$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains

$rule1 = '@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"
);'

$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"

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
);'

$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"

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);'
=> issue(claim = c2);'

$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);

@RuleName = "Issue issuerID 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/2008/06/identity/claims/issuerid",
Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}

$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
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/LiveID/Federation/2008/05/ImmutableID"),
query = ";objectguid;{0}",
param = c2.Value
);'
}

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

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

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

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules

$crSet.ClaimRulesString

Remarks
This script appends the rules to the existing rules. Do not run the script twice, because the set of rules would
be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding
conditions) before running the script again.
If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomain
cmdlet), set the value of $multipleVerifiedDomainNames in the script to $true . Also make sure that you
remove any existing issuerid claim that might have been created by Azure AD Connect or via other means.
Here's an example for this rule:

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =
regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));

If you have already issued an ImmutableID claim for user accounts, set the value of
$immutableIDAlreadyIssuedforUsers in the script to $true .

Enable Windows down-level devices

If some of your domain-joined devices are Windows down-level devices, you need to:
Set a policy in Azure AD to enable users to register devices.
Configure your on-premises federation service to issue claims to support Integrated Windows Authentication
(IWA) for device registration.
Add the Azure AD device authentication endpoint to the local intranet zones to avoid certificate prompts when
authenticating the device.
Control Windows down-level devices.
Set a policy in Azure AD to enable users to register devices
To register Windows down-level devices, make sure that the setting to allow users to register devices in Azure AD
is enabled. In the Azure portal, you can find this setting under Azure Active Director y > Users and groups >
Device settings .
The following policy must be set to All : Users may register their devices with Azure AD .

Configure the on-premises federation service

Your on-premises federation service must support issuing the authenticationmethod and wiaormultiauthn
claims when it receives an authentication request to the Azure AD relying party holding a resource_params
parameter with the following encoded value:

eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0

which decoded is {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}

When such a request comes, the on-premises federation service must authenticate the user by using Integrated
Windows Authentication. When authentication is successful, the federation service must issue the following two
claims:
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
http://schemas.microsoft.com/claims/wiaormultiauthn

In AD FS, you must add an issuance transform rule that passes through the authentication method. To add this rule:
1. In the AD FS management console, go to AD FS > Trust Relationships > Relying Par ty Trusts .
2. Right-click the Microsoft Office 365 Identity Platform relying party trust object, and then select Edit Claim
Rules .
3. On the Issuance Transform Rules tab, select Add Rule .
4. In the Claim rule template list, select Send Claims Using a Custom Rule .
5. Select Next .
6. In the Claim rule name box, enter Auth Method Claim Rule .
7. In the Claim rule box, enter the following rule:
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);

8. On your federation server, enter the following PowerShell command. Replace <RPObjectName> with the
relying party object name for your Azure AD relying party trust object. This object usually is named
Microsoft Office 365 Identity Platform .
Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences
wiaormultiauthn

Add the Azure AD device authentication endpoint to the local intranet zones
To avoid certificate prompts when users of registered devices authenticate to Azure AD, you can push a policy to
your domain-joined devices to add the following URL to the local intranet zone in Internet Explorer:
https://device.login.microsoftonline.com

Control Windows down-level devices

To register Windows down-level devices, you need to download and install a Windows Installer package (.msi)
from the Download Center. For more information, see the section Controlled validation of hybrid Azure AD join on
Windows down-level devices.

Verify joined devices

Here are 3 ways to locate and verify the device state:
Locally on the device
1. Open Windows PowerShell.
2. Enter dsregcmd /status .
3. Verify that both AzureAdJoined and DomainJoined are set to YES .
4. You can use the DeviceId and compare the status on the service using either the Azure portal or PowerShell.
Using the Azure portal
1. Go to the devices page using a direct link.
2. Information on how to locate a device can be found in How to manage device identities using the Azure portal.
3. If the Registered column says Pending , then Hybrid Azure AD Join has not completed. In federated
environments, this can happen only if it failed to register and AAD connect is configured to sync the devices.
4. If the Registered column contains a date/time , then Hybrid Azure AD Join has completed.
Using PowerShell
Verify the device registration state in your Azure tenant by using Get-MsolDevice . This cmdlet is in the Azure
Active Directory PowerShell module.
When you use the Get-MSolDevice cmdlet to check the service details:
An object with the device ID that matches the ID on the Windows client must exist.
The value for DeviceTrustType is Domain Joined . This setting is equivalent to the Hybrid Azure AD joined
state on the Devices page in the Azure AD portal.
For devices that are used in Conditional Access, the value for Enabled is True and DeviceTrustLevel is
Managed .
1. Open Windows PowerShell as an administrator.
2. Enter Connect-MsolService to connect to your Azure tenant.
Count all Hybrid Azure AD joined devices (excluding Pending state)

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

Count all Hybrid Azure AD joined devices with Pending state

(Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-

not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}).count

List all Hybrid Azure AD joined devices

Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and

(([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}

List all Hybrid Azure AD joined devices with Pending state

Get-MsolDevice -All -IncludeSystemManagedDevices | where {($_.DeviceTrustType -eq 'Domain Joined') -and (-

not([string]($_.AlternativeSecurityIds)).StartsWith("X509:"))}

List details of a single device:

1. Enter get-msoldevice -deviceId <deviceId> (This is the DeviceId obtained locally on the device).
2. Verify that Enabled is set to True .

Troubleshoot your implementation

If you experience issues completing hybrid Azure AD join for domain-joined Windows devices, see:
Troubleshooting devices using dsregcmd command
Troubleshooting hybrid Azure Active Directory joined devices
Troubleshooting hybrid Azure Active Directory joined down-level devices

Next steps
Introduction to device management in Azure Active Directory
 Tutorial: Join a new Windows 10 device with Azure
AD during a first run
9/7/2020 • 2 minutes to read • Edit Online

With device management in Azure Active Directory (Azure AD), you can ensure that your users are accessing your
resources from devices that meet your standards for security and compliance. For more information, see the
introduction to device management in Azure Active Directory.
With Windows 10, You can join a new device to Azure AD during the first-run experience (FRX).
This enables you to distribute shrink-wrapped devices to your employees or students.
If you have either Windows 10 Professional or Windows 10 Enterprise installed on a device, the experience defaults
to the setup process for company-owned devices.
In the Windows out-of-box experience, joining an on-premises Active Directory (AD) domain is not supported. If
you plan to join a computer to an AD domain, during setup, you should select the link Set up Windows with a
local account . You can then join the domain from the settings on your computer.
In this tutorial, you learn how to join a device to Azure AD during FRX:
Prerequisites
Joining a device
Verification

Prerequisites
To join a Windows 10 device, the device registration service must be configured to enable you to register devices.
In addition to having permission to joining devices in your Azure AD tenant, you must have fewer devices
registered than the configured maximum. For more information, see configure device settings.
In addition, if your tenant is federated, your Identity provider MUST support WS-Fed and WS-Trust
username/password endpoint. This can be version 1.3 or 2005. This protocol support is required to both join the
device to Azure AD and sign in to the device with a password.

Joining a device
To join a Windows 10 device to Azure AD during FRX:
1. When you turn on your new device and start the setup process, you should see the Getting Ready
message. Follow the prompts to set up your device.
2. Start by customizing your region and language. Then accept the Microsoft Software License Terms.
3. Select the network you want to use for connecting to the Internet.
4. Click This device belongs to my organization .

5. Enter the credentials that were provided to you by your organization, and then click Sign in .
 6. Your device locates a matching tenant in Azure AD. If you are in a federated domain, you are redirected to
your on-premises Secure Token Service (STS) server, for example, Active Directory Federation Services (AD
FS).
7. If you are a user in a non-federated domain, enter your credentials directly on the Azure AD-hosted page.
8. You are prompted for a multi-factor authentication challenge.
9. Azure AD checks whether an enrollment in mobile device management is required.
10. Windows registers the device in the organization’s directory in Azure AD and enrolls it in mobile device
management, if applicable.
11. If you are:
A managed user, Windows takes you to the desktop through the automatic sign-in process.
A federated user, you are directed to the Windows sign-in screen to enter your credentials.

Verification
To verify whether a device is joined to your Azure AD, review the Access work or school dialog on your Windows
device. The dialog should indicate that you are connected to your Azure AD directory.

Next steps
For more information, see the introduction to device management in Azure Active Directory.
For more information about managing devices in the Azure AD portal, see managing devices using the Azure
portal.
 Azure AD registered devices
9/7/2020 • 2 minutes to read • Edit Online

The goal of Azure AD registered devices is to provide your users with support for the Bring Your Own Device
(BYOD) or mobile device scenarios. In these scenarios, a user can access your organization’s Azure Active Directory
controlled resources using a personal device.

A Z URE A D REGIST ERED DESC RIP T IO N

Definition Registered to Azure AD without requiring organizational

account to sign in to the device

Primar y audience Applicable to all users with the following criteria:

Bring your own device (BYOD)

Mobile devices

Device ownership User or Organization

Operating Systems Windows 10, iOS, Android, and MacOS

Provisioning Windows 10 – Settings

iOS/Android – Company Portal or Microsoft Authenticator

app

MacOS – Company Portal

Device sign in options End-user local credentials

Password

Windows Hello

PIN

Biometrics or Pattern for other devices

Device management Mobile Device Management (example: Microsoft Intune)

Mobile Application Management

Key capabilities SSO to cloud resources

Conditional Access when enrolled into Intune

Conditional Access via App protection policy

 A Z URE A D REGIST ERED DESC RIP T IO N

Enables Phone sign in with Microsoft Authenticator app

Azure AD registered devices are signed in to using a local account like a Microsoft account on a Windows 10
device, but additionally have an Azure AD account attached for access to organizational resources. Access to
resources in the organization can be further limited based on that Azure AD account and Conditional Access
policies applied to the device identity.
Administrators can secure and further control these Azure AD registered devices using Mobile Device
Management (MDM) tools like Microsoft Intune. MDM provides a means to enforce organization-required
configurations like requiring storage to be encrypted, password complexity, and security software kept updated.
Azure AD registration can be accomplished when accessing a work application for the first time or manually using
the Windows 10 Settings menu.

Scenarios
A user in your organization wants to access tools for email, reporting time-off, and benefits enrollment from their
home PC. Your organization has these tools behind a Conditional Access policy that requires access from an Intune
compliant device. The user adds their organization account and registers their home PC with Azure AD and the
required Intune policies are enforced giving the user access to their resources.
Another user wants to access their organizational email on their personal Android phone that has been rooted.
Your company requires a compliant device and has created an Intune compliance policy to block any rooted
devices. The employee is stopped from accessing organizational resources on this device.

Next steps
Manage device identities using the Azure portal
Manage stale devices in Azure AD
 Azure AD joined devices
9/7/2020 • 3 minutes to read • Edit Online

Azure AD join is intended for organizations that want to be cloud-first or cloud-only. Any organization can deploy
Azure AD joined devices no matter the size or industry. Azure AD join works even in a hybrid environment,
enabling access to both cloud and on-premises apps and resources.

A Z URE A D JO IN DESC RIP T IO N

Definition Joined only to Azure AD requiring organizational account to

sign in to the device

Primar y audience Suitable for both cloud-only and hybrid organizations.

Applicable to all users in an organization

Device ownership Organization

Operating Systems All Windows 10 devices except Windows 10 Home

Windows Server 2019 Virtual Machines running in Azure

(Server core is not supported)

Provisioning Self-service: Windows OOBE or Settings

Bulk enrollment

Windows Autopilot

Device sign in options Organizational accounts using:

Password

Windows Hello for Business

FIDO2.0 security keys (preview)

Device management Mobile Device Management (example: Microsoft Intune)

Co-management with Microsoft Intune and Microsoft

Endpoint Configuration Manager

Key capabilities SSO to both cloud and on-premises resources

Conditional Access through MDM enrollment and MDM

compliance evaluation

Self-service Password Reset and Windows Hello PIN reset on

lock screen
 A Z URE A D JO IN DESC RIP T IO N

Enterprise State Roaming across devices

Azure AD joined devices are signed in to using an organizational Azure AD account. Access to resources in the
organization can be further limited based on that Azure AD account and Conditional Access policies applied to the
device identity.
Administrators can secure and further control Azure AD joined devices using Mobile Device Management (MDM)
tools like Microsoft Intune or in co-management scenarios using Microsoft Endpoint Configuration Manager. These
tools provide a means to enforce organization-required configurations like requiring storage to be encrypted,
password complexity, software installations, and software updates. Administrators can make organization
applications available to Azure AD joined devices using Configuration Manager to Manage apps from the
Microsoft Store for Business and Education.
Azure AD join can be accomplished using self-service options like the Out of Box Experience (OOBE), bulk
enrollment, or Windows Autopilot.
Azure AD joined devices can still maintain single sign-on access to on-premises resources when they are on the
organization's network. Devices that are Azure AD joined can still authenticate to on-premises servers like file,
print, and other applications.

Scenarios
While Azure AD join is primarily intended for organizations that do not have an on-premises Windows Server
Active Directory infrastructure, you can certainly use it in scenarios where:
You want to transition to cloud-based infrastructure using Azure AD and MDM like Intune.
You can’t use an on-premises domain join, for example, if you need to get mobile devices such as tablets and
phones under control.
Your users primarily need to access Office 365 or other SaaS apps integrated with Azure AD.
You want to manage a group of users in Azure AD instead of in Active Directory. This scenario can apply, for
example, to seasonal workers, contractors, or students.
You want to provide joining capabilities to workers in remote branch offices with limited on-premises
infrastructure.
You can configure Azure AD joined devices for all Windows 10 devices with the exception of Windows 10 Home.
The goal of Azure AD joined devices is to simplify:
Windows deployments of work-owned devices
Access to organizational apps and resources from any Windows device
Cloud-based management of work-owned devices
Users to sign in to their devices with their Azure AD or synced Active Directory work or school accounts.
Azure AD Join can be deployed by using any of the following methods:
Windows Autopilot
Bulk deployment
Self-service experience

Next steps
Plan your Azure AD join implementation
How to manage the local administrators group on Azure AD joined devices
Manage device identities using the Azure portal
Manage stale devices in Azure AD
 Hybrid Azure AD joined devices
9/7/2020 • 2 minutes to read • Edit Online

For more than a decade, many organizations have used the domain join to their on-premises Active Directory to
enable:
IT departments to manage work-owned devices from a central location.
Users to sign in to their devices with their Active Directory work or school accounts.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they
often use Configuration Manager or group policy (GP) to manage them.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by
Azure Active Directory, you can implement hybrid Azure AD joined devices. These devices, are devices that are
joined to your on-premises Active Directory and registered with your Azure Active Directory.

H Y B RID A Z URE A D JO IN DESC RIP T IO N

Definition Joined to on-premises AD and Azure AD requiring

organizational account to sign in to the device

Primar y audience Suitable for hybrid organizations with existing on-premises AD

infrastructure

Applicable to all users in an organization

Device ownership Organization

Operating Systems Windows 10, 8.1 and 7

Windows Server 2008/R2, 2012/R2, 2016 and 2019

Provisioning Windows 10, Windows Server 2016/2019

Domain join by IT and autojoin via Azure AD Connect or ADFS

config

Domain join by Windows Autopilot and autojoin via Azure AD

Connect or ADFS config

Windows 8.1, Windows 7, Windows Server 2012 R2, Windows

Server 2012, and Windows Server 2008 R2 - Require MSI

Device sign in options Organizational accounts using:

Password

Windows Hello for Business for Win10

Device management Group Policy

 H Y B RID A Z URE A D JO IN DESC RIP T IO N

Configuration Manager standalone or co-management with

Microsoft Intune

Key capabilities SSO to both cloud and on-premises resources

Conditional Access through Domain join or through Intune if

co-managed

Self-service Password Reset and Windows Hello PIN reset on

lock screen

Enterprise State Roaming across devices

Scenarios
Use Azure AD hybrid joined devices if:
You have Win32 apps deployed to these devices that rely on Active Directory machine authentication.
You want to continue to use Group Policy to manage device configuration.
You want to continue to use existing imaging solutions to deploy and configure devices.
You must support down-level Windows 7 and 8.1 devices in addition to Windows 10

Next steps
Plan your hybrid Azure AD join implementation
Manage device identities using the Azure portal
Manage stale devices in Azure AD
 How SSO to on-premises resources works on Azure
AD joined devices
9/7/2020 • 3 minutes to read • Edit Online

It is probably not a surprise that an Azure Active Directory (Azure AD) joined device gives you a single sign-on
(SSO) experience to your tenant's cloud apps. If your environment has an on-premises Active Directory (AD), you
can extend the SSO experience on these devices to resources and applications that rely on on-premises AD as well.
This article explains how this works.

Prerequisites
If Azure AD joined machines are not connected to your organization's network, a VPN or other network
infrastructure is required. On-premises SSO requires line-of-sight communication with your on-premises AD DS
domain controllers.

How it works
With an Azure AD joined device, your users already have an SSO experience to the cloud apps in your
environment. If your environment has an Azure AD and an on-premises AD, you may want to expand the scope of
your SSO experience to your on-premises Line Of Business (LOB) apps, file shares, and printers.
Azure AD joined devices have no knowledge about your on-premises AD environment because they aren't joined
to it. However, you can provide additional information about your on-premises AD to these devices with Azure AD
Connect.
An environment that has both, an Azure AD and an on-premises AD, is also known has hybrid environment. If you
have a hybrid environment, it is likely that you already have Azure AD Connect deployed to synchronize your on-
premises identity information to the cloud. As part of the synchronization process, Azure AD Connect synchronizes
on-premises user information to Azure AD. When a user signs in to an Azure AD joined device in a hybrid
environment:
1. Azure AD sends the details of the user's on-premises domain back to the device, along with the Primary Refresh
Token
2. The local security authority (LSA) service enables Kerberos and NTLM authentication on the device.
During an access attempt to a resource requesting Kerberos or NTLM in the user's on-premises environment, the
device:
1. Sends the on-premises domain information and user credentials to the located DC to get the user
authenticated.
2. Receives a Kerberos Ticket-Granting Ticket (TGT) or NTLM token based on the protocol the on-premises
resource or application supports. If the attempt to get the Kerberos TGT or NTLM token for the domain fails
(related DCLocator timeout can cause a delay), Credential Manager entries are attempted, or the user may
receive an authentication popup requesting credentials for the target resource.
All apps that are configured for Windows-Integrated authentication seamlessly get SSO when a user tries to
access them.
Windows Hello for Business requires additional configuration to enable on-premises SSO from an Azure AD joined
device. For more information, see Configure Azure AD joined devices for On-premises Single-Sign On using
Windows Hello for Business.

What you get

With SSO, on an Azure AD joined device you can:
Access a UNC path on an AD member server
Access an AD member web server configured for Windows-integrated security
If you want to manage your on-premises AD from a Windows device, install the Remote Server Administration
Tools for Windows 10.
You can use:
The Active Directory Users and Computers (ADUC) snap-in to administer all AD objects. However, you have to
specify the domain that you want to connect to manually.
The DHCP snap-in to administer an AD-joined DHCP server. However, you may need to specify the DHCP server
name or address.

What you should know

You may have to adjust your domain-based filtering in Azure AD Connect to ensure that the data about the
required domains is synchronized.
Apps and resources that depend on Active Directory machine authentication don't work because Azure AD joined
devices don't have a computer object in AD.
You can't share files with other users on an Azure AD-joined device.

Next steps
For more information, see What is device management in Azure Active Directory?
 What is a Primary Refresh Token?
9/7/2020 • 21 minutes to read • Edit Online

A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, iOS, and Android
devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-
on (SSO) across the applications used on those devices. In this article, we will provide details on how a PRT is
issued, used, and protected on Windows 10 devices.
This article assumes that you already understand the different device states available in Azure AD and how single
sign-on works in Windows 10. For more information about devices in Azure AD, see the article What is device
management in Azure Active Directory?

Key terminology and components

The following Windows components play a key role in requesting and using a PRT:
Cloud Authentication Provider (CloudAP): CloudAP is the modern authentication provider for Windows sign
in, that verifies users logging to a Windows 10 device. CloudAP provides a plugin framework that identity
providers can build on to enable authentication to Windows using that identity provider’s credentials.
Web Account Manager (WAM): WAM is the default token broker on Windows 10 devices. WAM also provides
a plugin framework that identity providers can build on and enable SSO to their applications relying on that
identity provider.
Azure AD CloudAP plugin : An Azure AD specific plugin built on the CloudAP framework, that verifies user
credentials with Azure AD during Windows sign in.
Azure AD WAM plugin : An Azure AD specific plugin built on the WAM framework, that enables SSO to
applications that rely on Azure AD for authentication.
Dsreg : An Azure AD specific component on Windows 10, that handles the device registration process for all
device states.
Trusted Platform Module (TPM): A TPM is a hardware component built into a device, that provides hardware-
based security functions for user and device secrets. More details can be found in the article Trusted Platform
Module Technology Overview.

What does the PRT contain?

A PRT contains claims generally contained in any Azure AD refresh token. In addition, there are some device-
specific claims included in the PRT. They are as follows:
Device ID : A PRT is issued to a user on a specific device. The device ID claim deviceID determines the device
the PRT was issued to the user on. This claim is later issued to tokens obtained via the PRT. The device ID claim is
used to determine authorization for Conditional Access based on device state or compliance.
Session key : The session key is an encrypted symmetric key, generated by the Azure AD authentication
service, issued as part of the PRT. The session key acts as the proof of possession when a PRT is used to obtain
tokens for other applications.
Can I see what’s in a PRT?
A PRT is an opaque blob sent from Azure AD whose contents are not known to any client components. You cannot
see what’s inside a PRT.

How is a PRT issued?

Device registration is a prerequisite for device based authentication in Azure AD. A PRT is issued to users only on
registered devices. For more in-depth details on device registration, see the article Windows Hello for Business and
Device Registration. During device registration, the dsreg component generates two sets of cryptographic key
pairs:
Device key (dkpub/dkpriv)
Transport key (tkpub/tkpriv)
The private keys are bound to the device’s TPM if the device has a valid and functioning TPM, while the public keys
are sent to Azure AD during the device registration process. These keys are used to validate the device state during
PRT requests.
The PRT is issued during user authentication on a Windows 10 device in two scenarios:
Azure AD joined or Hybrid Azure AD joined : A PRT is issued during Windows logon when a user signs in
with their organization credentials. A PRT is issued with all Windows 10 supported credentials, for example,
password and Windows Hello for Business. In this scenario, Azure AD CloudAP plugin is the primary authority
for the PRT.
Azure AD registered device : A PRT is issued when a user adds a secondary work account to their Windows
10 device. Users can add an account to Windows 10 in two different ways -
Adding an account via the Use this account ever ywhere on this device prompt after signing in to
an app (for example, Outlook)
Adding an account from Settings > Accounts > Access Work or School > Connect
In Azure AD registered device scenarios, the Azure AD WAM plugin is the primary authority for the PRT since
Windows logon is not happening with this Azure AD account.

NOTE
3rd party identity providers need to support the WS-Trust protocol to enable PRT issuance on Windows 10 devices. Without
WS-Trust, PRT cannot be issued to users on Hybrid Azure AD joined or Azure AD joined devices. On ADFS only
usernamemixed endpoints are required. Both adfs/services/trust/2005/windowstransport and
adfs/services/trust/13/windowstransport should be enabled as intranet facing endpoints only and must NOT be exposed
as extranet facing endpoints through the Web Application Proxy

What is the lifetime of a PRT?

Once issued, a PRT is valid for 14 days and is continuously renewed as long as the user actively uses the device.

How is a PRT used?

A PRT is used by two key components in Windows:
Azure AD CloudAP plugin : During Windows sign in, the Azure AD CloudAP plugin requests a PRT from Azure
AD using the credentials provided by the user. It also caches the PRT to enable cached sign in when the user
does not have access to an internet connection.
Azure AD WAM plugin : When users try to access applications, the Azure AD WAM plugin uses the PRT to
enable SSO on Windows 10. Azure AD WAM plugin uses the PRT to request refresh and access tokens for
applications that rely on WAM for token requests. It also enables SSO on browsers by injecting the PRT into
browser requests. Browser SSO in Windows 10 is supported on Microsoft Edge (natively) and Chrome (via the
Windows 10 Accounts or Office Online extensions).

How is a PRT renewed?

A PRT is renewed in two different methods:
Azure AD CloudAP plugin ever y 4 hours : The CloudAP plugin renews the PRT every 4 hours during
Windows sign in. If the user does not have internet connection during that time, CloudAP plugin will renew the
PRT after the device is connected to the internet.
Azure AD WAM plugin during app token requests : The WAM plugin enables SSO on Windows 10 devices
by enabling silent token requests for applications. The WAM plugin can renew the PRT during these token
requests in two different ways:
An app requests WAM for an access token silently but there’s no refresh token available for that app. In
this case, WAM uses the PRT to request a token for the app and gets back a new PRT in the response.
An app requests WAM for an access token but the PRT is invalid or Azure AD requires additional
authorization (for example, Azure Multi-Factor Authentication). In this scenario, WAM initiates an
interactive logon requiring the user to reauthenticate or provide additional verification and a new PRT is
issued on successful authentication.
In an ADFS environment, direct line of sight to the domain controller isn't required to renew the PRT. PRT renewal
requires only /adfs/services/trust/2005/usernamemixed and /adfs/services/trust/13/usernamemixed endpoints
enabled on proxy by using WS-Trust protocol.
Windows transport endpoints are required for password authentication only when a password is changed, not for
PRT renewal.
Key considerations
A PRT is only issued and renewed during native app authentication. A PRT is not renewed or issued during a
browser session.
In Azure AD joined and hybrid Azure AD joined devices, the CloudAP plugin is the primary authority for a PRT. If
a PRT is renewed during a WAM-based token request, the PRT is sent back to CloudAP plugin, which verifies the
validity of the PRT with Azure AD before accepting it.

How is the PRT protected?

A PRT is protected by binding it to the device the user has signed in to. Azure AD and Windows 10 enable PRT
protection through the following methods:
During first sign in : During first sign in, a PRT is issued by signing requests using the device key
cryptographically generated during device registration. On a device with a valid and functioning TPM, the
device key is secured by the TPM preventing any malicious access. A PRT is not issued if the corresponding
device key signature cannot be validated.
During token requests and renewal : When a PRT is issued, Azure AD also issues an encrypted session key
to the device. It is encrypted with the public transport key (tkpub) generated and sent to Azure AD as part of
device registration. This session key can only be decrypted by the private transport key (tkpriv) secured by the
TPM. The session key is the Proof-of-Possession (POP) key for any requests sent to Azure AD. The session key is
also protected by the TPM and no other OS component can access it. Token requests or PRT renewal requests
are securely signed by this session key through the TPM and hence, cannot be tampered with. Azure AD will
invalidate any requests from the device that are not signed by the corresponding session key.
By securing these keys with the TPM, malicious actors cannot steal the keys nor replay the PRT elsewhere as the
TPM is inaccessible even if an attacker has physical possession of the device. Thus, using a TPM greatly enhances
the security of Azure AD Joined, Hybrid Azure AD joined, and Azure AD registered devices against credential theft.
For performance and reliability, TPM 2.0 is the recommended version for all Azure AD device registration scenarios
on Windows 10.
How are app tokens and browser cookies protected?
App tokens : When an app requests token through WAM, Azure AD issues a refresh token and an access token.
However, WAM only returns the access token to the app and secures the refresh token in its cache by encrypting it
with the user’s data protection application programming interface (DPAPI) key. WAM securely uses the refresh
token by signing requests with the session key to issue further access tokens. The DPAPI key is secured by an Azure
AD based symmetric key in Azure AD itself. When the device needs to decrypt the user profile with the DPAPI key,
Azure AD provides the DPAPI key encrypted by the session key, which CloudAP plugin requests TPM to decrypt.
This functionality ensures consistency in securing refresh tokens and avoids applications implementing their own
protection mechanisms.
Browser cookies : In Windows 10, Azure AD supports browser SSO in Internet Explorer and Microsoft Edge
natively or in Google Chrome via the Windows 10 accounts extension. The security is built not only to protect the
cookies but also the endpoints to which the cookies are sent. Browser cookies are protected the same way a PRT is,
by utilizing the session key to sign and protect the cookies.
When a user initiates a browser interaction, the browser (or extension) invokes a COM native client host. The native
client host ensures that the page is from one of the allowed domains. The browser could send other parameters to
the native client host, including a nonce, however the native client host guarantees validation of the hostname. The
native client host requests a PRT-cookie from CloudAP plugin, which creates and signs it with the TPM-protected
session key. As the PRT-cookie is signed by the session key, it cannot be tampered with. This PRT-cookie is included
in the request header for Azure AD to validate the device it is originating from. If using the Chrome browser, only
the extension explicitly defined in the native client host’s manifest can invoke it preventing arbitrary extensions
from making these requests. Once Azure AD validates the PRT cookie, it issues a session cookie to the browser. This
session cookie also contains the same session key issued with a PRT. During subsequent requests, the session key
is validated effectively binding the cookie to the device and preventing replays from elsewhere.

When does a PRT get an MFA claim?

A PRT can get a multi-factor authentication (MFA) claim in specific scenarios. When an MFA-based PRT is used to
request tokens for applications, the MFA claim is transferred to those app tokens. This functionality provides a
seamless experience to users by preventing MFA challenge for every app that requires it. A PRT can get an MFA
claim in the following ways:
Sign in with Windows Hello for Business : Windows Hello for Business replaces passwords and uses
cryptographic keys to provide strong two-factor authentication. Windows Hello for Business is specific to a user
on a device, and itself requires MFA to provision. When a user logs in with Windows Hello for Business, the
user’s PRT gets an MFA claim. This scenario also applies to users logging in with smartcards if smartcard
authentication produces an MFA claim from ADFS.
As Windows Hello for Business is considered multi-factor authentication, the MFA claim is updated when
the PRT itself is refreshed, so the MFA duration will continually extend when users sign in with WIndows
Hello for Business
MFA during WAM interactive sign in : During a token request through WAM, if a user is required to do MFA
to access the app, the PRT that is renewed during this interaction is imprinted with an MFA claim.
In this case, the MFA claim is not updated continuously, so the MFA duration is based on the lifetime set
on the directory.
When a previous existing PRT and RT are used for access to an app, the PRT and RT will be regarded as
the first proof of authentication. A new AT will be required with a second proof and an imprinted MFA
claim. This will also issue a new PRT and RT.
MFA during device registration : If an admin has configured their device settings in Azure AD to require MFA
to register devices, the user needs to do MFA to complete the registration. During this process, the PRT that is
issued to the user has the MFA claim obtained during the registration. This capability only applies to the user
who did the join operation, not to other users who sign in to that device.
Similar to the WAM interactive sign in, the MFA claim is not updated continuously, so the MFA duration is
based on the lifetime set on the directory.
Windows 10 maintains a partitioned list of PRTs for each credential. So, there’s a PRT for each of Windows Hello for
Business, password, or smartcard. This partitioning ensures that MFA claims are isolated based on the credential
used, and not mixed up during token requests.

How is a PRT invalidated?

A PRT is invalidated in the following scenarios:
Invalid user : If a user is deleted or disabled in Azure AD, their PRT is invalidated and cannot be used to obtain
tokens for applications. If a deleted or disabled user already signed in to a device before, cached sign-in would
log them in, until CloudAP is aware of their invalid state. Once CloudAP determines that the user is invalid, it
blocks subsequent logons. An invalid user is automatically blocked from sign in to new devices that don’t have
their credentials cached.
Invalid device : If a device is deleted or disabled in Azure AD, the PRT obtained on that device is invalidated and
cannot be used to obtain tokens for other applications. If a user is already signed in to an invalid device, they
can continue to do so. But all tokens on the device are invalidated and the user does not have SSO to any
resources from that device.
Password change : After a user changes their password, the PRT obtained with the previous password is
invalidated by Azure AD. Password change results in the user getting a new PRT. This invalidation can happen in
two different ways:
If user signs in to Windows with their new password, CloudAP discards the old PRT and requests Azure
AD to issue a new PRT with their new password. If user does not have an internet connection, the new
password cannot be validated, Windows may require the user to enter their old password.
If a user has logged in with their old password or changed their password after signing into Windows,
the old PRT is used for any WAM-based token requests. In this scenario, the user is prompted to
reauthenticate during the WAM token request and a new PRT is issued.
TPM issues : Sometimes, a device’s TPM can falter or fail, leading to inaccessibility of keys secured by the TPM.
In this case, the device is incapable of getting a PRT or requesting tokens using an existing PRT as it cannot
prove possession of the cryptographic keys. As a result, any existing PRT is invalidated by Azure AD. When
Windows 10 detects a failure, it initiates a recovery flow to re-register the device with new cryptographic keys.
With Hybrid Azure Ad join, just like the initial registration, the recovery happens silently without user input. For
Azure AD joined or Azure AD registered devices, the recovery needs to be performed by a user who has
administrator privileges on the device. In this scenario, the recovery flow is initiated by a Windows prompt that
guides the user to successfully recover the device.

Detailed flows
The following diagrams illustrate the underlying details in issuing, renewing, and using a PRT to request an access
token for an application. In addition, these steps also describe how the aforementioned security mechanisms are
applied during these interactions.
PRT issuance during first sign in
NOTE
In Azure AD joined devices, this exchange happens synchronously to issue a PRT before the user can logon to Windows. In
hybrid Azure AD joined devices, on-premises Active Directory is the primary authority. So, the user is only waiting until they
can acquire a TGT to login, while the PRT issuance happens asynchronously. This scenario does not apply to Azure AD
registered devices as logon does not use Azure AD credentials.

ST EP DESC RIP T IO N

A User enters their password in the sign in UI. LogonUI passes

the credentials in an auth buffer to LSA, which in turns passes
it internally to CloudAP. CloudAP forwards this request to the
CloudAP plugin.

B CloudAP plugin initiates a realm discovery request to identify

the identity provider for the user. If user’s tenant has a
federation provider setup, Azure AD returns the federation
provider’s Metadata Exchange endpoint (MEX) endpoint. If
not, Azure AD returns that the user is managed indicating
that user can authenticate with Azure AD.
 ST EP DESC RIP T IO N

C If the user is managed, CloudAP will get the nonce from Azure
AD. If the user is federated, CloudAP plugin requests a SAML
token from the federation provider with the user’s credentials.
Once it receives, the SAML token, it requests a nonce from
Azure AD.

D CloudAP plugin constructs the authentication request with the

user’s credentials, nonce, and a broker scope, signs the
request with the Device key (dkpriv) and sends it to Azure AD.
In a federated environment, CloudAP plugin uses the SAML
token returned by the federation provider instead of the user’
credentials.

E Azure AD validates the user credentials, the nonce, and device

signature, verifies that the device is valid in the tenant and
issues the encrypted PRT. Along with the PRT, Azure AD also
issues a symmetric key, called the Session key encrypted by
Azure AD using the Transport key (tkpub). In addition, the
Session key is also embedded in the PRT. This Session key acts
as the Proof-of-possession (PoP) key for subsequent requests
with the PRT.

F CloudAP plugin passes the encrypted PRT and Session key to

CloudAP. CloudAP request the TPM to decrypt the Session key
using the Transport key (tkpriv) and re-encrypt it using the
TPM’s own key. CloudAP stores the encrypted Session key in
its cache along with the PRT.

PRT renewal in subsequent logons

ST EP DESC RIP T IO N

A User enters their password in the sign in UI. LogonUI passes

the credentials in an auth buffer to LSA, which in turns passes
it internally to CloudAP. CloudAP forwards this request to the
CloudAP plugin.

B If the user has previously logged on to the user, Windows

initiates cached sign in and validates credentials to log the
user in. Every 4 hours, the CloudAP plugin initiates PRT
renewal asynchronously.

C CloudAP plugin initiates a realm discovery request to identify

the identity provider for the user. If user’s tenant has a
federation provider setup, Azure AD returns the federation
provider’s Metadata Exchange endpoint (MEX) endpoint. If
not, Azure AD returns that the user is managed indicating
that user can authenticate with Azure AD.
 ST EP DESC RIP T IO N

D If the user is federated, CloudAP plugin requests a SAML

token from the federation provider with the user’s credentials.
Once it receives, the SAML token, it requests a nonce from
Azure AD. If the user is managed, CloudAP will directly get the
nonce from Azure AD.

E CloudAP plugin constructs the authentication request with the

user’s credentials, nonce, and the existing PRT, signs the
request with the Session key and sends it to Azure AD. In a
federated environment, CloudAP plugin uses the SAML token
returned by the federation provider instead of the user’
credentials.

F Azure AD validates the Session key signature by comparing it

against the Session key embedded in the PRT, validates the
nonce and verifies that the device is valid in the tenant and
issues a new PRT. As seen before, the PRT is again
accompanied with the Session key encrypted by Transport key
(tkpub).

G CloudAP plugin passes the encrypted PRT and Session key to

CloudAP. CloudAP requests the TPM to decrypt the Session
key using the Transport key (tkpriv) and re-encrypt it using
the TPM’s own key. CloudAP stores the encrypted Session key
in its cache along with the PRT.

NOTE
A PRT can be renewed externally without the need of a VPN connection when usernamemixed endpoints are enabled
externally.

PRT usage during app token requests

ST EP DESC RIP T IO N

A An application (for example, Outlook, OneNote etc.) initiates a

token request to WAM. WAM, in turn, asks the Azure AD
WAM plugin to service the token request.

B If a Refresh token for the application is already available, Azure

AD WAM plugin uses it to request an access token. To provide
proof of device binding, WAM plugin signs the request with
the Session key. Azure AD validates the Session key and issues
an access token and a new refresh token for the app,
encrypted by the Session key. WAM plugin requests Cloud AP
plugin to decrypt the tokens, which, in turn, requests the TPM
to decrypt using the Session key, resulting in WAM plugin
getting both the tokens. Next, WAM plugin provides only the
access token to the application, while it re-encrypts the
refresh token with DPAPI and stores it in its own cache
 ST EP DESC RIP T IO N

C If a Refresh token for the application is not available, Azure AD

WAM plugin uses the PRT to request an access token. To
provide proof of possession, WAM plugin signs the request
containing the PRT with the Session key. Azure AD validates
the Session key signature by comparing it against the Session
key embedded in the PRT, verifies that the device is valid and
issues an access token and a refresh token for the application.
in addition, Azure AD can issue a new PRT (based on refresh
cycle), all of them encrypted by the Session key.

D WAM plugin requests Cloud AP plugin to decrypt the tokens,

which, in turn, requests the TPM to decrypt using the Session
key, resulting in WAM plugin getting both the tokens. Next,
WAM plugin provides only the access token to the application,
while it re-encrypts the refresh token with DPAPI and stores it
in its own cache. WAM plugin will use the refresh token going
forward for this application. WAM plugin also gives back the
new PRT to Cloud AP plugin, which validates the PRT with
Azure AD before updating it in its own cache. Cloud AP plugin
will use the new PRT going forward.

E WAM provides the newly issued access token to WAM, which

in turn, provides it back to the calling application

Browser SSO using PRT

ST EP DESC RIP T IO N
 ST EP DESC RIP T IO N

A User logs in to Windows with their credentials to get a PRT.

Once user opens the browser, browser (or extension) loads the
URLs from the registry.

B When a user opens an Azure AD login URL, the browser or

extension validates the URL with the ones obtained from the
registry. If they match, the browser invokes the native client
host for getting a token.

C The native client host validates that the URLs belong to the
Microsoft identity providers (Microsoft account or Azure AD),
extracts a nonce sent from the URL and makes a call to
CloudAP plugin to get a PRT cookie.

D The CloudAP plugin will create the PRT cookie, sign in with the
TPM-bound session key and send it back to the native client
host. As the cookie is signed by the session key, it cannot be
tampered with.

E The native client host will return this PRT cookie to the
browser, which will include it as part of the request header
called x-ms-RefreshTokenCredential and request tokens from
Azure AD.

F Azure AD validates the Session key signature on the PRT

cookie, validates the nonce, verifies that the device is valid in
the tenant, and issues an ID token for the web page and an
encrypted session cookie for the browser.

Next steps
For more information on troubleshooting PRT-related issues, see the article Troubleshooting hybrid Azure Active
Directory joined Windows 10 and Windows Server 2016 devices.
 Understand secure, Azure-managed workstations
3/6/2020 • 8 minutes to read • Edit Online

Secured, isolated workstations are critically important for the security of sensitive roles like administrators,
developers, and critical service operators. If client workstation security is compromised, many security controls and
assurances can fail or be ineffective.
This document explains what you need for building a secure workstation, often known as a privileged access
workstation (PAW). The article also contains detailed instructions to set up initial security controls. This guidance
describes how cloud-based technology can manage the service. It relies on security capabilities that were
introduced in Windows 10RS5, Microsoft Defender Advanced Threat Protection (ATP), Azure Active Directory, and
Microsoft Intune.

NOTE
This article explains the concept of a secure workstation and its importance. If you are already familiar with the concept and
would like to skip to deployment, visit Deploy a Secure Workstation.

Why secure workstation access is important

The rapid adoption of cloud services and the ability to work from anywhere has created a new exploitation method.
By exploiting weak security controls on devices where administrators work, attackers can gain access to privileged
resources.
Privileged misuse and supply chain attacks are among the top five methods that attackers use to breach
organizations. They're also the second most commonly detected tactics in incidents reported in 2018 according to
the Verizon Threat report, and the Security Intelligence Report.
Most attackers follow these steps:
1. Reconnaissance to find a way in, often specific to an industry.
2. Analysis to collect information and identify the best way to infiltrate a workstation that is perceived as low value.
3. Persistence to look for a means to move laterally.
4. Exfiltration of confidential and sensitive data.
During reconnaissance, attackers frequently infiltrate devices that seem low risk or undervalued. They use these
vulnerable devices to locate an opportunity for lateral movement and to find administrative users and devices.
After they gain access to privileged user roles, attackers identify high value data and successfully exfiltrate that data.

This document describes a solution that can help protect your computing devices from such lateral attacks. The
solution isolates management and services from less valuable productivity devices, breaking the chain before the
device that has access to sensitive cloud resources can be infiltrated. The solution uses native Azure services that
are part of the Microsoft 365 Enterprise stack:
Intune for device management and a safe list of applications and URLs
Autopilot for device setup, deployment, and refresh
Azure AD for user management, Conditional Access, and multi-factor authentication
Windows 10 (current version) for device health attestation and user experience
Defender ATP for cloud-managed endpoint protection, detection, and response
Azure AD PIM for managing authorization and just-in-time (JIT) privileged access to resources
Log Analytics, and Sentinel for monitoring and alerting

Who benefits from a secure workstation?

All users and operators benefit when using a secure workstation. An attacker who compromises a PC or device can
impersonate all cached accounts. When logged in to the device, they might also use credentials and tokens. This
risk makes it important to secure devices that are used for privileged roles, including administrative rights. Devices
with privileged accounts are targets for lateral movement and privilege escalation attacks. These accounts can be
used for a variety of assets such as:
Administrator of on-premises or cloud-based systems
Developer workstation for critical systems
Social media account administrator with high exposure
Highly sensitive workstation, such as a SWIFT payment terminal
Workstation handling trade secrets
To reduce risk, you should implement elevated security controls for privileged workstations that make use of these
accounts. For more information, see the Azure Active Directory feature deployment guide, Office 365 roadmap, and
Securing Privileged Access roadmap).

Why use dedicated workstations?

While it's possible to add security to an existing device, it's better to start with a secure foundation. To put your
organization in the best position to maintain a high security level, start with a device you know is secure and
implement a set of known security controls.
A growing number of attack vectors through email and web browsing makes it increasingly hard to be sure that a
device can be trusted. This guide assumes that a dedicated workstation is isolated from standard productivity,
browsing, and email. Removal of productivity, web browsing, and email from a device can have a negative impact
on productivity. However, this safeguard is typically acceptable for scenarios where the job tasks don’t explicitly
require it and risk of a security incident is high.

NOTE
Web browsing here refers to general access to arbitrary websites which can be a high risk activity. Such browsing is distinctly
different from using a web browser to access a small number of well-known administrative websites for services like Azure,
Office 365, other cloud providers, and SaaS applications.

Containment strategies tighten security by increasing the number and type of controls that deter an attacker from
gaining access sensitive assets. The model described in this article uses a tiered privilege design and restricts
administrative privileges to specific devices.
Supply chain management
Essential to a secured workstation is a supply chain solution where you use a trusted workstation called the 'root of
trust'. Technology that must be considered in the selection of the root of trust hardware should include the
following technologies included in modern laptops:
Trusted Platform Module (TPM) 2.0
BitLocker Drive Encryption
UEFI Secure Boot
Drivers and Firmware Distributed through Windows Update
Virtualization and HVCI Enabled
Drivers and Apps HVCI-Ready
Windows Hello
DMA I/O Protection
System Guard
Modern Standby
For this solution, root of trust will be deployed using Microsoft Autopilot technology with hardware that meets the
modern technical requirements. To secure a workstation, Autopilot lets you leverage Microsoft OEM-optimized
Windows 10 devices. These devices come in a known good state from the manufacturer. Instead of reimaging a
potentially insecure device, Autopilot can transform a Windows device into a “business-ready” state. It applies
settings and policies, installs apps, and even changes the edition of Windows 10. For example, Autopilot might
change a device's Windows installation from Windows 10 Pro to Windows 10 Enterprise so that it can use
advanced features.
Device roles and profiles
This guidance references several security profiles and roles that can help you create more secure solutions for
users, developers, and IT personnel. These profiles balance usability and risks for common users that can benefit
from an enhanced or secure workstation. The settings configurations provided here are based on industry accepted
standards. This guidance shows how to harden Windows 10 and reduce the risks associated with device or user
compromise. To take advantage of the modern hardware technology and root of trust device, we will use Device
Health Attestation, which is enabled starting at the High Security profile. This capability is present to ensure the
attackers cannot be persistent during the early boot of a device. It does so by using policy and technology to help
manage security features and risks.

Basic Security – A managed, standard workstation provides a good starting point for most home and
small business use. These devices are registered in Azure AD and managed with Intune. This profile permits
users to run any applications and browse any website. An anti-malware solution like Microsoft Defender
should be enabled.
Enhanced Security – This entry-level, protected solution is good for home users, small business users, and
general developers.
The enhanced workstation is a policy-based way to increase the security of the low security profile. It
provides a secure means to work with customer data while also using productivity tools like email and web
browsing. You can use audit policies and Intune to monitor an enhanced workstation for user behavior and
profile usage. You deploy the enhanced workstation profile with the Windows10 (1809) script, and it takes
advantage of advanced malware protection using Advanced Threat Protection (ATP).
High Security – The most effective means to reduce the attack surface of a workstation is to remove the
ability to self-administer the workstation. Removing local administrative rights is a step that improves
security, but it can impact productivity if implemented incorrectly. The high security profile builds on the
enhanced security profile with one considerable change: the removal of the local admin. This profile is
designed for high profile users: executives, payroll and sensitive data users, approvers for services and
processes.
The high security user demands a more controlled environment while still being able to do activities such as
email and web browsing in a simple-to-use experience. The users expect features such as cookies, favorites,
and other shortcuts to work. However, these users may not require the ability to modify or debug their
device. They also don't need to install drivers. The high security profile is deployed using the High Security -
Windows10 (1809) script.
Specialized – Attackers target developers and IT administrators because they can alter systems of interest
to the attackers. The specialized workstation expands on the policies of the high security workstation by
managing local applications and limiting websites. It also restricts high-risk productivity capabilities such as
ActiveX, Java, browser plugins, and other Windows controls. You deploy this profile with the
DeviceConfiguration_NCSC - Windows10 (1803) SecurityBaseline script.
Secured – An attacker who compromises an administrative account can cause significant business damage
by data theft, data alteration, or service disruption. In this hardened state, the workstation enables all the
 security controls and policies that restrict direct control of local application management. A secured
workstation has no productivity tools so the device more difficult to compromise. It blocks the most
common vector for phishing attacks: email and social media. The secured workstation can be deployed with
the Secure Workstation - Windows10 (1809) SecurityBaseline script.

A secure workstation provides an administrator with a hardened workstation that has clear application
control and application guard. The workstation uses credential guard, device guard, and exploit guard to
protect the host from malicious behavior. All local disks are also encrypted with BitLocker.
Isolated – This custom, offline scenario represents the extreme end of the spectrum. No installation scripts
are provided for this case. You might need to manage a business-critical function that requires an
unsupported or unpatched legacy operating system. For example, a high value production line or a life-
support system. Because security is critical and cloud services are unavailable, you can manage and update
these computers manually or with an isolated Active Directory forest architecture such as the Enhanced
Security Admin Environment (ESAE). In these circumstances, consider removing all access except basic
Intune and ATP health checks.
Intune network communications requirement
ATP network communications requirement

Next steps
Deploy a secure Azure-managed workstation.
 Plan your Azure Active Directory device deployment
9/7/2020 • 9 minutes to read • Edit Online

This article helps you evaluate the methods to integrate your device with Azure AD, choose the implementation
plan, and provides key links to supported device management tools.
The landscape of devices from which your users sign in is expanding. Organizations may provide desktops, laptops,
phones, tablets, and other devices. Your users may bring their own array of devices, and access information from
varied locations. In this environment, your job as an administrator is to keep your organizational resources secure
across all devices.
Azure Active Directory (Azure AD) enables your organization to meet these goals with device identity management.
You can now get your devices in Azure AD and control them from a central location in the Azure portal. This gives
you a unified experience, enhanced security, and reduces the time needed to configure a new device.
There are multiple methods to integrate your devices into Azure AD:
You can register devices with Azure AD
Join devices to Azure AD (cloud-only) or
Create a hybrid Azure AD join in between devices in your on-premises Active Directory and Azure AD.

Learn
Before you begin, make sure that you're familiar with the device identity management overview.
Benefits
The key benefits of giving your devices an Azure AD identity:
Increase productivity – With Azure AD, your users can do seamless sign-on (SSO) to your on-premises and
cloud resources, which enables them to be productive wherever they are.
Increase security – Azure AD devices enable you to apply Conditional Access (CA) policies to resources based
on the identity of the device or user. CA policies can offer extra protection using Azure AD Identity Protection.
Joining a device to Azure AD is a prerequisite for increasing your security with a Passwordless
Authentication strategy.
Improve user experience – With device identities in Azure AD, you can provide your users with easy access to
your organization’s cloud-based resources from both personal and corporate devices. Administrators can
enable Enterprise State Roaming for a unified experience across all Windows devices.
Simplify deployment and management – Device identity management simplifies the process of bringing
devices to Azure AD with Windows Autopilot, bulk provisioning, and self-service: Out of Box Experience
(OOBE). You can manage these devices with Mobile Device Management (MDM) tools like Microsoft Intune,
and their identities in Azure portal.
Training resources
Video: Conditional access with device controls
FAQs: Azure AD device management FAQ and Settings and data roaming FAQ

Plan the deployment project

Consider your organizational needs while you determine the strategy for this deployment in your environment.
Engage the right stakeholders
When technology projects fail, they typically do so due to mismatched expectations on impact, outcomes, and
responsibilities. To avoid these pitfalls, ensure that you are engaging the right stakeholders and that stakeholder
roles in the project are well understood.
For this plan, add the following stakeholders to your list:

RO L E DESC RIP T IO N

Device administrator A representative from the device team that can verify that the
plan will meet the device requirements of your organization.

Network administrator A representative from the network team that can make sure
to meet network requirements.

Device management team Team that manages inventory of devices.

OS-specific admin teams Teams that support and manage specific OS versions. For
example, there may be a Mac or iOS focused team.

Plan communications
Communication is critical to the success of any new service. Proactively communicate with your users how their
experience will change, when it will change, and how to gain support if they experience issues.
Plan a pilot
We recommend that the initial configuration of your integration method is in a test environment, or with a small
group of test devices. See Best practices for a pilot.
Hybrid Azure AD join deployment is straightforward, and it's 100% an administrator’s task without end user action
necessary. You may want to do a controlled validation of hybrid Azure AD join before enabling it across the entire
organization all at once.

Choose your integration methods

Your organization can use multiple device integration methods in a single Azure AD tenant. The goal is to choose
the method(s) suitable to get your devices securely managed in Azure AD. There are many parameters that drive
this decision including ownership, device types, primary audience, and your organization’s infrastructure.
The following information can help you decide which integration methods to use.
Decision tree for devices integration
Use this tree to determine options for organization-owned devices.

NOTE
Personal or bring-your-own device (BYOD) scenarios are not pictured in this diagram. They always result in Azure AD
registration.
Comparison matrix
iOS and Android devices may only be Azure AD registered. The following table presents high-level considerations
for Windows client devices. Use it as an overview, then explore the different integration methods in detail.

C O N SIDERAT IO N A Z URE A D REGIST ERED A Z URE A D JO IN H Y B RID A Z URE A D JO IN

Client operating systems

Windows 10 devices

Windows down-level devices

(Windows 8.1 or Windows 7)

Sign in options

End-user local credentials

Password

Device PIN

Windows Hello

Windows Hello for Business

FIDO 2.0 security keys

Microsoft Authenticator App

(passwordless)
 C O N SIDERAT IO N A Z URE A D REGIST ERED A Z URE A D JO IN H Y B RID A Z URE A D JO IN

Key capabilities

SSO to cloud resources

SSO to on-premises
resources

Conditional Access
(Require devices be marked
as compliant)
(Must be managed by
MDM)

Conditional Access
(Require hybrid Azure AD
joined devices)

Self-service password reset

from windows login screen

Windows hello PIN reset

Enterprise state roaming

across devices

Azure AD Registration
Registered devices are often managed with Microsoft Intune. Devices are enrolled in Intune in a number of ways,
depending on the operating system.
Azure AD registered devices provide support for Bring Your Own Devices (BYOD) and corporate owned devices to
SSO to cloud resources. Access to resources is based on the Azure AD CA policies applied to the device and the
user.
Registering devices
Registered devices are often managed with Microsoft Intune. Devices are enrolled in Intune in a number of ways,
depending on the operating system.
BYOD and corporate owned mobile device are registered by users installing the Company portal app.
iOS
Android
Windows 10
If registering your devices is the best option for your organization, see the following resources:
This overview of Azure AD registered devices.
This end-user documentation on Register your personal device on your organization’s network.

Azure AD join
Azure AD join enables you to transition towards a cloud-first model with Windows. It provides a great foundation if
you're planning to modernize your device management and reduce device-related IT costs. Azure AD join works
with Windows 10 devices only. Consider it as the first choice for new devices.
However, Azure AD joined devices can SSO to on-premises resources when they are on the organization's network,
can authenticate to on-premises servers like file, print, and other applications.
If this is the best option for your organization, see the following resources:
This overview of Azure AD joined devices.
Familiarize yourself with the Azure AD Join implementation plan.
Provisioning Azure AD Join to your devices
To provision Azure AD Join, you have the following approaches:
Self-Service: Windows 10 first-run experience
If you have either Windows 10 Professional or Windows 10 Enterprise installed on a device, the experience defaults
to the setup process for company-owned devices.
Windows Out of Box Experience (OOBE) or from Windows Settings
Windows Autopilot
Bulk Enrollment
Choose your deployment procedure after careful comparison of these approaches.
You may determine that Azure AD Join is the best solution for a device, and that device may already be in a
different states. Here are the upgrade considerations.

C URREN T DEVIC E STAT E DESIRED DEVIC E STAT E H O W - TO

On-premises domain joined Azure AD Join Unjoin the device from on-premises
domain before joining to Azure AD

Hybrid Azure AD Join Azure AD Join Unjoin the device from on-premises
domain and from Azure AD before
joining to Azure AD

Azure AD registered Azure AD Join Unregister the device before joining to

Azure AD

Hybrid Azure AD join

If you have an on-premises Active Directory environment and you want to join your Active directory domain-joined
computers to Azure AD, you can accomplish this with hybrid Azure AD join. It supports a broad range of Windows
devices, including both Windows current and Windows down-level devices.
Most organizations already have domain joined devices and manage them via Group Policy or System Center
Configuration Manager (SCCM). In that case, we recommend configuring hybrid Azure AD Join to start getting
benefits while leveraging existing investment.
If hybrid Azure AD join is the best option for your organization, see the following resources:
This overview of Hybrid Azure AD joined devices.
Familiarize yourself with the Hybrid Azure AD join implementation plan.
Provisioning hybrid Azure AD join to your devices
Review your identity infrastructure. Azure AD Connect provides you with a wizard to configure hybrid Azure AD
Join for:
Federated domains
Managed domains
If installing the required version of Azure AD Connect isn't an option for you, see how to manually configure Hybrid
Azure AD join.

NOTE
The on-premises domain-joined Windows 10 device attempts to auto-join to Azure AD to become Hybrid Azure AD joined
by default. This will only succeed if you haves set up the right environment.

You may determine that Hybrid Azure AD Join is the best solution for a device, and that device may already be in a
different state. Here are the upgrade considerations.

C URREN T DEVIC E STAT E DESIRED DEVIC E STAT E H O W - TO

On-premises domain join Hybrid Azure AD Join Use Azure AD connect or AD FS to join
to Azure

On-premises workgroup joined or new Hybrid Azure AD Join Supported with Windows Autopilot.
Otherwise device needs to be on-
premises domain joined before Hybrid
Azure AD Join

Azure AD joined Hybrid Azure AD Join Unjoin from Azure AD, which puts it in
the on-premises workgroup or new
state.

Azure AD registerd Hybrid Azure AD Join Depends on Windows version. See

these considerations.

Manage your devices

Once you have registered or joined your devices to Azure AD, use the Azure portal as a central place to manage
your device identities. The Azure Active Directory devices page enables you to:
Configure your device settings
You need to be a local administrator to manage Windows devices. Azure AD updates this membership for Azure
AD joined devices, automatically adding those with the device manager role as administrators to all joined
devices.
Make sure that you keep the environment clean by managing stale devices, and focus your resources on managing
current devices.
Review device-related audit logs
Supported device management tools
Administrators can secure and further control these registered and joined devices using additional device
management tools. These tools provide a means to enforce organization-required configurations like requiring
storage to be encrypted, password complexity, software installations, and software updates.
Review supported and unsupported platforms for integrated devices:
 DEVIC E
M A N A GEM EN T A Z URE A D H Y B RID A Z URE A D
TO O L S REGIST ERED A Z URE A D JO IN JO IN

Mobile Device
Management (MDM)
Example: Microsoft
Intune

Co management with
Microsoft Intune and
Microsoft Endpoint
Configuration
Manager
(Windows 10 and
later)

Group policy
(Windows only)

We recommend that you consider Microsoft Intune Mobile Application management (MAM) with or without device
management for registered iOS or Android devices.
Administrators can also deploy virtual desktop infrastructure (VDI) platforms hosting Windows operating systems
in their organizations to streamline management and reduce costs through consolidation and centralization of
resources.
Troubleshoot device identities
Troubleshooting devices using the dsregcmd command
Troubleshooting Enterprise State Roaming settings in Azure Active Directory
If you experience issues with completing hybrid Azure AD join for domain-joined Windows devices, see:
Troubleshoot hybrid Azure AD join for Windows current devices
Troubleshoot hybrid Azure AD join for Windows down level devices

Next steps
Plan your Azure AD Join implementation
Plan your hybrid Azure AD Join implementation
Manage device identities
 How to: Plan your Azure AD join implementation
9/7/2020 • 10 minutes to read • Edit Online

Azure AD join allows you to join devices directly to Azure AD without the need to join to on-premises Active
Directory while keeping your users productive and secure. Azure AD join is enterprise-ready for both at-scale and
scoped deployments.
This article provides you with the information you need to plan your Azure AD join implementation.

Prerequisites
This article assumes that you are familiar with the Introduction to device management in Azure Active Directory.

Plan your implementation

To plan your Azure AD join implementation, you should familiarize yourself with:
Review your scenarios
Review your identity infrastructure
Assess your device management
Understand considerations for applications and resources
Understand your provisioning options
Configure enterprise state roaming
Configure Conditional Access

Review your scenarios

While Hybrid Azure AD join may be preferred for certain scenarios, Azure AD join enables you to transition
towards a cloud-first model with Windows. If you are planning to modernize your devices management and
reduce device-related IT costs, Azure AD join provides a great foundation towards achieving those objectives.
You should consider Azure AD join if your goals align with the following criteria:
You are adopting Microsoft 365 as the productivity suite for your users.
You want to manage devices with a cloud device management solution.
You want to simplify device provisioning for geographically distributed users.
You plan to modernize your application infrastructure.

Review your identity infrastructure

Azure AD join works with both, managed and federated environments.
Managed environment
A managed environment can be deployed either through Password Hash Sync or Pass Through Authentication
with Seamless Single Sign On.
These scenarios don't require you to configure a federation server for authentication.
Federated environment
A federated environment should have an identity provider that supports both WS-Trust and WS-Fed protocols:
 WS-Fed: This protocol is required to join a device to Azure AD.
WS-Trust: This protocol is required to sign in to an Azure AD joined device.
When you're using AD FS, you need to enable the following WS-Trust endpoints:
/adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed
/adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed

If your identity provider does not support these protocols, Azure AD join does not work natively.

NOTE
Currently, Azure AD join does not work with AD FS 2019 configured with external authentication providers as the primary
authentication method. Azure AD join defaults to password authentication as the primary method, which results in
authentication failures in this scenario

Smartcards and certificate -based authentication

You can't use smartcards or certificate-based authentication to join devices to Azure AD. However, smartcards can
be used to sign in to Azure AD joined devices if you have AD FS configured.
Recommendation: Implement Windows Hello for Business for strong, password-less authentication to Windows
10 devices.
User configuration
If you create users in your:
On-premises Active Director y , you need to synchronize them to Azure AD using Azure AD Connect.
Azure AD , no additional setup is required.
On-premises UPNs that are different from Azure AD UPNs are not supported on Azure AD joined devices. If your
users use an on-premises UPN, you should plan to switch to using their primary UPN in Azure AD.

Assess your device management

Supported devices
Azure AD join:
Is only applicable to Windows 10 devices.
Is not applicable to previous versions of Windows or other operating systems. If you have Windows 7/8.1
devices, you must upgrade to Windows 10 to deploy Azure AD join.
Is supported for FIPS-compliant TPM 2.0 but not supported for TPM 1.2. If your devices have FIPS-compliant
TPM 1.2, you must disable them before proceeding with Azure AD join. Microsoft does not provide any tools
for disabling FIPS mode for TPMs as it is dependent on the TPM manufacturer. Please contact your hardware
OEM for support.
Recommendation: Always use the latest Windows 10 release to take advantage of updated features.
Management platform
Device management for Azure AD joined devices is based on an MDM platform such as Intune, and MDM CSPs.
Windows 10 has a built-in MDM agent that works with all compatible MDM solutions.

NOTE
Group policies are not supported in Azure AD joined devices as they are not connected to on-premises Active Directory.
Management of Azure AD joined devices is only possible through MDM
There are two approaches for managing Azure AD joined devices:
MDM-only - A device is exclusively managed by an MDM provider like Intune. All policies are delivered as part
of the MDM enrollment process. For Azure AD Premium or EMS customers, MDM enrollment is an automated
step that is part of an Azure AD join.
Co-management - A device is managed by an MDM provider and SCCM. In this approach, the SCCM agent is
installed on an MDM-managed device to administer certain aspects.
If you are using group policies, evaluate your MDM policy parity by using the MDM Migration Analysis Tool
(MMAT).
Review supported and unsupported policies to determine whether you can use an MDM solution instead of Group
policies. For unsupported policies, consider the following:
Are the unsupported policies necessary for Azure AD joined devices or users?
Are the unsupported policies applicable in a cloud driven deployment?
If your MDM solution is not available through the Azure AD app gallery, you can add it following the process
outlined in Azure Active Directory integration with MDM.
Through co-management, you can use SCCM to manage certain aspects of your devices while policies are
delivered through your MDM platform. Microsoft Intune enables co-management with SCCM. For more
information on co-management for Windows 10 devices, see What is co-management?. If you use an MDM
product other than Intune, please check with your MDM provider on applicable co-management scenarios.
Recommendation: Consider MDM only management for Azure AD joined devices.

Understand considerations for applications and resources

We recommend migrating applications from on-premises to cloud for a better user experience and access control.
However, Azure AD joined devices can seamlessly provide access to both, on-premises and cloud applications. For
more information, see How SSO to on-premises resources works on Azure AD joined devices.
The following sections list considerations for different types of applications and resources.
Cloud-based applications
If an application is added to Azure AD app gallery, users get SSO through Azure AD joined devices. No additional
configuration is required. Users get SSO on both, Microsoft Edge and Chrome browsers. For Chrome, you need to
deploy the Windows 10 Accounts extension.
All Win32 applications that:
Rely on Web Account Manager (WAM) for token requests also get SSO on Azure AD joined devices.
Don't rely on WAM may prompt users for authentication.
On-premises web applications
If your apps are custom built and/or hosted on-premises, you need to add them to your browser’s trusted sites to:
Enable Windows integrated authentication to work
Provide a no-prompt SSO experience to users.
If you use AD FS, see Verify and manage single sign-on with AD FS.
Recommendation: Consider hosting in the cloud (for example, Azure) and integrating with Azure AD for a better
experience.
On-premises applications relying on legacy protocols
Users get SSO from Azure AD joined devices if the device has access to a domain controller.
Recommendation: Deploy Azure AD App proxy to enable secure access for these applications.
On-premises network shares
Your users have SSO from Azure AD joined devices when a device has access to an on-premises domain controller.
Printers
For printers, you need to deploy hybrid cloud print for discovering printers on Azure AD joined devices.
While printers can't be automatically discovered in a cloud only environment, your users can also use the printers’
UNC path to directly add them.
On-premises applications relying on machine authentication
Azure AD joined devices don't support on-premises applications relying on machine authentication.
Recommendation: Consider retiring these applications and moving to their modern alternatives.
Remote Desktop Services
Remote desktop connection to an Azure AD joined devices requires the host machine to be either Azure AD joined
or Hybrid Azure AD joined. Remote desktop from an unjoined or non-Windows device is not supported. For more
information, see Connect to remote Azure AD joined pc
Starting Windows 10 2004 update, users can alo use remote desktop from an Azure AD registered Windows 10
device to an Azure AD joined device.

Understand your provisioning options

You can provision Azure AD join using the following approaches:
Self-ser vice in OOBE/Settings - In the self-service mode, users go through the Azure AD join process either
during Windows Out of Box Experience (OOBE) or from Windows Settings. For more information, see Join your
work device to your organization's network.
Windows Autopilot - Windows Autopilot enables pre-configuration of devices for a smoother experience in
OOBE to perform an Azure AD join. For more information, see the Overview of Windows Autopilot.
Bulk enrollment - Bulk enrollment enables an administrator driven Azure AD join by using a bulk
provisioning tool to configure devices. For more information, see Bulk enrollment for Windows devices.
Here’s a comparison of these three approaches

EL EM EN T SEL F - SERVIC E SET UP W IN DO W S A UTO P ILOT B UL K EN RO L L M EN T

Require user interaction to Yes Yes No

set up

Require IT effort No Yes Yes

Applicable flows OOBE & Settings OOBE only OOBE only

Local admin rights to Yes, by default Configurable No

primary user

Require device OEM support No Yes No

Supported versions 1511+ 1709+ 1703+

Choose your deployment approach or approaches by reviewing the table above and reviewing the following
considerations for adopting either approach:
 Are your users tech savvy to go through the setup themselves?
Self-service can work best for these users. Consider Windows Autopilot to enhance the user experience.
Are your users remote or within corporate premises?
Self-service or Autopilot work best for remote users for a hassle-free setup.
Do you prefer a user driven or an admin-managed configuration?
Bulk enrollment works better for admin driven deployment to set up devices before handing over to
users.
Do you purchase devices from 1-2 OEMS, or do you have a wide distribution of OEM devices?
If purchasing from limited OEMs who also support Autopilot, you can benefit from tighter integration
with Autopilot.

Configure your device settings

The Azure portal allows you to control the deployment of Azure AD joined devices in your organization. To
configure the related settings, on the Azure Active Director y page , select Devices > Device settings .
Users may join devices to Azure AD
Set this option to All or Selected based on the scope of your deployment and who you want to allow to setup an
Azure AD joined device.

Additional local administrators on Azure AD joined devices

Choose Selected and selects the users you want to add to the local administrators’ group on all Azure AD joined
devices.

Require multi-factor Auth to join devices

Select “Yes if you require users to perform MFA while joining devices to Azure AD. For the users joining devices to
Azure AD using MFA, the device itself becomes a 2nd factor.

Configure your mobility settings

Before you can configure your mobility settings, you may have to add an MDM provider, first.
To add an MDM provider :
1. On the Azure Active Director y page , in the Manage section, click Mobility (MDM and MAM) .
2. Click Add application .
3. Select your MDM provider from the list.
Select your MDM provider to configure the related settings.
MDM user scope
Select Some or All based on the scope of your deployment.

Based on your scope, one of the following happens:

User is in MDM scope : If you have an Azure AD Premium subscription, MDM enrollment is automated along
with Azure AD join. All scoped users must have an appropriate license for your MDM. If MDM enrollment fails
in this scenario, Azure AD join will also be rolled back.
User is not in MDM scope : If users are not in MDM scope, Azure AD join completes without any MDM
enrollment. This results in an unmanaged device.
MDM URLs
There are three URLs that are related to your MDM configuration:
MDM terms of use URL
MDM discovery URL
MDM compliance URL

Each URL has a predefined default value. If these fields are empty, please contact your MDM provider for more
information.
MAM settings
MAM does not apply to Azure AD join.
Configure enterprise state roaming
If you want to enable state roaming to Azure AD so that users can sync their settings across devices, see Enable
Enterprise State Roaming in Azure Active Directory.
Recommendation : Enable this setting even for hybrid Azure AD joined devices.

Configure Conditional Access

If you have an MDM provider configured for your Azure AD joined devices, the provider flags the device as
compliant as soon as the device is under management.

You can use this implementation to require managed devices for cloud app access with Conditional Access.

Next steps
Join a new Windows 10 device with Azure AD during a first run Join your work device to your organization's
network
 How to manage the local administrators group on
Azure AD joined devices
9/7/2020 • 5 minutes to read • Edit Online

To manage a Windows device, you need to be a member of the local administrators group. As part of the Azure
Active Directory (Azure AD) join process, Azure AD updates the membership of this group on a device. You can
customize the membership update to satisfy your business requirements. A membership update is, for example,
helpful if you want to enable your helpdesk staff to do tasks requiring administrator rights on a device.
This article explains how the local administrators membership update works and how you can customize it during
an Azure AD Join. The content of this article doesn't apply to a hybrid Azure AD joined devices.

How it works
When you connect a Windows device with Azure AD using an Azure AD join, Azure AD adds the following security
principals to the local administrators group on the device:
The Azure AD global administrator role
The Azure AD device administrator role
The user performing the Azure AD join
By adding Azure AD roles to the local administrators group, you can update the users that can manage a device
anytime in Azure AD without modifying anything on the device. Currently, you cannot assign groups to an
administrator role. Azure AD also adds the Azure AD device administrator role to the local administrators group to
support the principle of least privilege (PoLP). In addition to the global administrators, you can also enable users
that have been only assigned the device administrator role to manage a device.

Manage the global administrators role

To view and update the membership of the global administrator role, see:
View all members of an administrator role in Azure Active Directory
Assign a user to administrator roles in Azure Active Directory

Manage the device administrator role

In the Azure portal, you can manage the device administrator role on the Devices page. To open the Devices
page:
1. Sign in to your Azure portal as a global administrator.
2. Search for and select Azure Active Directory.
3. In the Manage section, click Devices .
4. On the Devices page, click Device settings .
To modify the device administrator role, configure Additional local administrators on Azure AD joined
devices .
 NOTE
This option requires an Azure AD Premium tenant.

Device administrators are assigned to all Azure AD joined devices. You cannot scope device administrators to a
specific set of devices. Updating the device administrator role doesn't necessarily have an immediate impact on the
affected users. On devices where a user is already signed into, the privilege elevation takes place when both the
below actions happen:
Upto 4 hours have passed for Azure AD to issue a new Primary Refresh Token with the appropriate privileges.
User signs out and signs back in, not lock/unlock, to refresh their profile.

NOTE
The above actions are not applicable to users who have not signed in to the relevant device previously. In this case, the
administrator privileges are applied immediately after their first sign-in to the device.

Manage administrator privileges using Azure AD groups (preview)

NOTE
This feature is currently in preview.

Starting with Windows 10 2004 update, you can use Azure AD groups to manage administrator privileges on
Azure AD joined devices with the Restricted Groups MDM policy. This policy allows you to assign individual users
or Azure AD groups to the local administrators group on an Azure AD joined device, providing you the granularity
to configure distinct administrators for different groups of devices.
Currently, there's no UI in Intune to manage this policy and needs to be configured using Custom OMA-URI
Settings. A few considerations for this policy:
Adding Azure AD groups through the policy requires the group's SID that can be obtained by executing the
Groups API. The SID is defined by the property securityIdentifier in the Groups API.
When Restricted Groups policy is enforced, any current member of the group that is not on the Members list is
removed. So enforcing this policy with new members or groups will remove the existing administrators namely
user who joined the device, the Device administrator role and Global administrator role from the device. To
avoid removing existing members, you need to configure them as part of the Members list in the Restricted
Groups policy.
This policy is only applicable to the following well-known groups on a Windows 10 device - Administrators,
Users, Guests, Power Users, Remote Desktop Users and Remote Management Users.
Managing local administrators using Restricted Groups policy is not applicable to Hybrid Azure AD joined or
Azure AD Registered devices.
While the Restricted Groups policy existed prior to Windows 10 2004 update, it did not support Azure AD
groups as members of a device's local administrators group.
Manage regular users
By default, Azure AD adds the user performing the Azure AD join to the administrator group on the device. If you
want to prevent regular users from becoming local administrators, you have the following options:
Windows Autopilot - Windows Autopilot provides you with an option to prevent primary user performing the
join from becoming a local administrator. You can accomplish this by creating an Autopilot profile.
Bulk enrollment - An Azure AD join that is performed in the context of a bulk enrollment happens in the context
of an auto-created user. Users signing in after a device has been joined are not added to the administrators
group.

Manually elevate a user on a device

In addition to using the Azure AD join process, you can also manually elevate a regular user to become a local
administrator on one specific device. This step requires you to already be a member of the local administrators
group.
Starting with the Windows 10 1709 release, you can perform this task from Settings -> Accounts -> Other
users . Select Add a work or school user , enter the user's UPN under User account and select Administrator
under Account type
Additionally, you can also add users using the command prompt:
If your tenant users are synchronized from on-premises Active Directory, use
net localgroup administrators /add "Contoso\username" .
If your tenant users are created in Azure AD, use net localgroup administrators /add "AzureAD\UserUpn"

Considerations
You cannot assign groups to the device administrator role, only individual users are allowed.
Device administrators are assigned to all Azure AD Joined devices. They can't be scoped to a specific set of devices.
When you remove users from the device administrator role, they still have the local administrator privilege on a
device as long as they are signed in to it. The privilege is revoked during their next sign-in when a new primary
refresh token is issued. This revocation, similar to the privilege elevation, could take upto 4 hours.

Next steps
To get an overview of how to manage device in the Azure portal, see managing devices using the Azure portal
To learn more about device-based Conditional Access, see configure Azure Active Directory device-based
Conditional Access policies.
 How To: Plan your hybrid Azure Active Directory
join implementation
9/7/2020 • 8 minutes to read • Edit Online

In a similar way to a user, a device is another core identity you want to protect and use it to protect your
resources at any time and from any location. You can accomplish this goal by bringing and managing device
identities in Azure AD using one of the following methods:
Azure AD join
Hybrid Azure AD join
Azure AD registration
By bringing your devices to Azure AD, you maximize your users' productivity through single sign-on (SSO)
across your cloud and on-premises resources. At the same time, you can secure access to your cloud and on-
premises resources with Conditional Access.
If you have an on-premises Active Directory (AD) environment and you want to join your AD domain-joined
computers to Azure AD, you can accomplish this by doing hybrid Azure AD join. This article provides you with
the related steps to implement a hybrid Azure AD join in your environment.

Prerequisites
This article assumes that you are familiar with the Introduction to device identity management in Azure Active
Directory.

NOTE
The minimum required domain controller version for Windows 10 hybrid Azure AD join is Windows Server 2008 R2.

Plan your implementation

To plan your hybrid Azure AD implementation, you should familiarize yourself with:
Review supported devices
Review things you should know
Review controlled validation of hybrid Azure AD join
Select your scenario based on your identity infrastructure
Review on-premises AD UPN support for hybrid Azure AD join

Review supported devices

Hybrid Azure AD join supports a broad range of Windows devices. Because the configuration for devices
running older versions of Windows requires additional or different steps, the supported devices are grouped
into two categories:
Windows current devices
Windows 10
Windows Server 2016
Note : Azure National cloud customers require version 1809
 Windows Server 2019
For devices running the Windows desktop operating system, supported version are listed in this article
Windows 10 release information. As a best practice, Microsoft recommends you upgrade to the latest version of
Windows 10.
Windows down-level devices
Windows 8.1
Windows 7 support ended on January 14, 2020. For more information, see Support for Windows 7 has
ended.
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2. For support information on Windows Server 2008 and 2008 R2, see Prepare for
Windows Server 2008 end of support.
As a first planning step, you should review your environment and determine whether you need to support
Windows down-level devices.

Review things you should know

Unsupported scenarios
Hybrid Azure AD join is currently not supported if your environment consists of a single AD forest
synchronizing identity data to more than one Azure AD tenant.
Hybrid Azure AD join is not supported for Windows Server running the Domain Controller (DC) role.
Hybrid Azure AD join is not supported on Windows down-level devices when using credential roaming
or user profile roaming or mandatory profile.
Server Core OS doesn't support any type of device registration.
OS imaging considerations
If you are relying on the System Preparation Tool (Sysprep) and if you are using a pre-Windows 10
1809 image for installation, make sure that image is not from a device that is already registered with
Azure AD as Hybrid Azure AD join.
If you are relying on a Virtual Machine (VM) snapshot to create additional VMs, make sure that snapshot
is not from a VM that is already registered with Azure AD as Hybrid Azure AD join.
If you are using Unified Write Filter and similar technologies that clear changes to the disk at reboot, they
must be applied after the device is Hybrid Azure AD joined. Enabling such technologies prior to
completion of Hybrid Azure AD join will result in the device getting unjoined on every reboot
Handling devices with Azure AD registered state
If your Windows 10 domain joined devices are Azure AD registered to your tenant, it could lead to a dual state
of Hybrid Azure AD joined and Azure AD registered device. We recommend upgrading to Windows 10 1803
(with KB4489894 applied) or above to automatically address this scenario. In pre-1803 releases, you will need
to remove the Azure AD registered state manually before enabling Hybrid Azure AD join. In 1803 and above
releases, the following changes have been made to avoid this dual state:
Any existing Azure AD registered state for a user would be automatically removed
after the device is Hybrid Azure AD joined and the same user logs in. For example, if User A had an Azure AD
registered state on the device, the dual state for User A is cleaned up only when User A logs in to the device.
If there are multiple users on the same device, the dual state is cleaned up individually when those users log
in. In addition to removing the Azure AD registered state, Windows 10 will also unenroll the device from
 Intune or other MDM, if the enrollment happened as part of the Azure AD registration via auto-enrollment.
You can prevent your domain joined device from being Azure AD registered by adding the following registry
value to HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin:
"BlockAADWorkplaceJoin"=dword:00000001.
In Windows 10 1803, if you have Windows Hello for Business configured, the user needs to re-setup
Windows Hello for Business after the dual state clean up.This issue has been addressed with KB4512509

NOTE
Even though Windows 10 automatically removes the Azure AD registered state locally, the device object in Azure AD is
not immediately deleted if it is managed by Intune. You can validate the removal of Azure AD registered state by running
dsregcmd /status and consider the device not to be Azure AD registered based on that.

Additional considerations
If your environment uses virtual desktop infrastructure (VDI), see Device identity and desktop
virtualization.
Hybrid Azure AD join is supported for FIPS-compliant TPM 2.0 and not supported for TPM 1.2. If your
devices have FIPS-compliant TPM 1.2, you must disable them before proceeding with Hybrid Azure AD
join. Microsoft does not provide any tools for disabling FIPS mode for TPMs as it is dependent on the
TPM manufacturer. Please contact your hardware OEM for support.
Starting from Windows 10 1903 release, TPMs 1.2 are not used with hybrid Azure AD join and devices
with those TPMs will be considered as if they don't have a TPM.

Review controlled validation of hybrid Azure AD join

When all of the pre-requisites are in place, Windows devices will automatically register as devices in your Azure
AD tenant. The state of these device identities in Azure AD is referred as hybrid Azure AD join. More information
about the concepts covered in this article can be found in the article Introduction to device identity management
in Azure Active Directory.
Organizations may want to do a controlled validation of hybrid Azure AD join before enabling it across their
entire organization all at once. Review the article controlled validation of hybrid Azure AD join to understand
how to accomplish it.

Select your scenario based on your identity infrastructure

Hybrid Azure AD join works with both, managed and federated environments depending on whether the UPN is
routable or non-routable. See bottom of the page for table on supported scenarios.
Managed environment
A managed environment can be deployed either through Password Hash Sync (PHS) or Pass Through
Authentication (PTA) with Seamless Single Sign On.
These scenarios don't require you to configure a federation server for authentication.

NOTE
Cloud authentication using Staged rollout is only supported starting Windows 10 1903 update

Federated environment
A federated environment should have an identity provider that supports the following requirements. If you have
a federated environment using Active Directory Federation Services (AD FS), then the below requirements are
already supported.
WIAORMULTIAUTHN claim: This claim is required to do hybrid Azure AD join for Windows down-level
devices.
WS-Trust protocol: This protocol is required to authenticate Windows current hybrid Azure AD joined
devices with Azure AD. When you're using AD FS, you need to enable the following WS-Trust endpoints:
/adfs/services/trust/2005/windowstransport
/adfs/services/trust/13/windowstransport
/adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed
/adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed

WARNING
Both adfs/ser vices/trust/2005/windowstranspor t or adfs/ser vices/trust/13/windowstranspor t should be
enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web
Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see Disable WS-Trust Windows
endpoints on the proxy. You can see what endpoints are enabled through the AD FS management console under Ser vice
> Endpoints .

NOTE
Azure AD does not support smartcards or certificates in managed domains.

Beginning with version 1.1.819.0, Azure AD Connect provides you with a wizard to configure hybrid Azure AD
join. The wizard enables you to significantly simplify the configuration process. If installing the required version
of Azure AD Connect is not an option for you, see how to manually configure device registration.
Based on the scenario that matches your identity infrastructure, see:
Configure hybrid Azure Active Directory join for federated environment
Configure hybrid Azure Active Directory join for managed environment

Review on-premises AD users UPN support for Hybrid Azure AD join

Sometimes, your on-premises AD users UPNs could be different from your Azure AD UPNs. In such cases,
Windows 10 Hybrid Azure AD join provides limited support for on-premises AD UPNs based on the
authentication method, domain type and Windows 10 version. There are two types of on-premises AD UPNs
that can exist in your environment:
Routable users UPN: A routable UPN has a valid verified domain, that is registered with a domain registrar.
For example, if contoso.com is the primary domain in Azure AD, contoso.org is the primary domain in on-
premises AD owned by Contoso and verified in Azure AD
Non-routable users UPN: A non-routable UPN does not have a verified domain. It is applicable only within
your organization's private network. For example, if contoso.com is the primary domain in Azure AD,
contoso.local is the primary domain in on-premises AD but is not a verifiable domain in the internet and only
used within Contoso's network.

NOTE
The information in this section applies only to an on-premises users UPN. It isn't applicable to an on-premises computer
domain suffix (example: computer1.contoso.local).

The table below provides details on support for these on-premises AD UPNs in Windows 10 Hybrid Azure AD
join

T Y P E O F O N - P REM ISES A D
UP N DO M A IN T Y P E W IN DO W S 10 VERSIO N DESC RIP T IO N

Routable Federated From 1703 release Generally available

Non-routable Federated From 1803 release Generally available

Routable Managed From 1803 release Generally available, Azure

AD SSPR on Windows
lockscreen is not supported

Non-routable Managed Not supported

Next steps
Configure hybrid Azure Active Directory join for federated environment Configure hybrid Azure Active
Directory join for managed environment
 Controlled validation of hybrid Azure AD join
9/7/2020 • 4 minutes to read • Edit Online

When all of the pre-requisites are in place, Windows devices will automatically register as devices in your Azure
AD tenant. The state of these device identities in Azure AD is referred as hybrid Azure AD join. More information
about the concepts covered in this article can be found in the articles Introduction to device management in Azure
Active Directory and Plan your hybrid Azure Active Directory join implementation.
Organizations may want to do a controlled validation of hybrid Azure AD join before enabling it across their entire
organization all at once. This article will explain how to accomplish a controlled validation of hybrid Azure AD join.

Controlled validation of hybrid Azure AD join on Windows current

devices
For devices running the Windows desktop operating system, the supported version is the Windows 10
Anniversary Update (version 1607) or later. As a best practice, upgrade to the latest version of Windows 10.
To do a controlled validation of hybrid Azure AD join on Windows current devices, you need to:
1. Clear the Service Connection Point (SCP) entry from Active Directory (AD) if it exists
2. Configure client-side registry setting for SCP on your domain-joined computers using a Group Policy Object
(GPO)
3. If you are using AD FS, you must also configure the client-side registry setting for SCP on your AD FS server
using a GPO
4. You may also need to customize synchronization options in Azure AD Connect to enable device
synchronization.
Clear the SCP from AD
Use the Active Directory Services Interfaces Editor (ADSI Edit) to modify the SCP objects in AD.
1. Launch the ADSI Edit desktop application from and administrative workstation or a domain controller as an
Enterprise Administrator.
2. Connect to the Configuration Naming Context of your domain.
3. Browse to CN=Configuration,DC=contoso,DC=com > CN=Ser vices > CN=Device Registration
Configuration
4. Right click on the leaf object CN=62a0ff2e-97b9-4513-943f-0d221bd30080 and select Proper ties
a. Select keywords from the Attribute Editor window and click Edit
b. Select the values of azureADId and azureADName (one at a time) and click Remove
5. Close ADSI Edit
Configure client-side registry setting for SCP
Use the following example to create a Group Policy Object (GPO) to deploy a registry setting configuring an SCP
entry in the registry of your devices.
1. Open a Group Policy Management console and create a new Group Policy Object in your domain.
a. Provide your newly created GPO a name (for example, ClientSideSCP).
2. Edit the GPO and locate the following path: Computer Configuration > Preferences > Windows Settings
> Registr y
3. Right-click on the Registry and select New > Registr y Item
 a. On the General tab, configure the following
a. Action: Update
b. Hive: HKEY_LOCAL_MACHINE
c. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
d. Value name: TenantId
e. Value type: REG_SZ
f. Value data: The GUID or Director y ID of your Azure AD instance (This value can be found in the
Azure por tal > Azure Active Director y > Proper ties > Director y ID )
b. Click OK
4. Right-click on the Registry and select New > Registr y Item
a. On the General tab, configure the following
a. Action: Update
b. Hive: HKEY_LOCAL_MACHINE
c. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
d. Value name: TenantName
e. Value type: REG_SZ
f. Value data: Your verified domain name if you are using federated environment such as AD FS.
Your verified domain name or your onmicrosoft.com domain name for example,
contoso.onmicrosoft.com if you are using managed environment
b. Click OK
5. Close the editor for the newly created GPO
6. Link the newly created GPO to the desired OU containing domain-joined computers that belong to your
controlled rollout population
Configure AD FS settings
If you are using AD FS, you first need to configure client-side SCP using the instructions mentioned above by
linking the GPO to your AD FS servers. The SCP object defines the source of authority for device objects. It can be
on-premises or Azure AD. When client-side SCP is configured for AD FS, the source for device objects is
established as Azure AD.

NOTE
If you failed to configure client-side SCP on your AD FS servers, the source for device identities would be considered as on-
premises. ADFS will then start deleting device objects from on-premises directory after the stipulated period defined in the
ADFS Device Registration's attribute "MaximumInactiveDays". ADFS Device Registration objects can be found using the Get-
AdfsDeviceRegistration cmdlet.

Controlled validation of hybrid Azure AD join on Windows down-level

devices
To register Windows down-level devices, organizations must install Microsoft Workplace Join for non-Windows
10 computers available on the Microsoft Download Center.
You can deploy the package by using a software distribution system likeMicrosoft Endpoint Configuration
Manager. The package supports the standard silent installation options with the quiet parameter. The current
branch of Configuration Manager offers benefits over earlier versions, like the ability to track completed
registrations.
The installer creates a scheduled task on the system that runs in the user context. The task is triggered when the
user signs in to Windows. The task silently joins the device with Azure AD with the user credentials after
authenticating with Azure AD.
To control the device registration, you should deploy the Windows Installer package to your selected group of
Windows down-level devices.

NOTE
If a SCP is not configured in AD, then you should follow the same approach as described to Configure client-side registry
setting for SCP) on your domain-joined computers using a Group Policy Object (GPO).

After you verify that everything works as expected, you can automatically register the rest of your Windows
current and down-level devices with Azure AD by configuring SCP using Azure AD Connect.

Next steps
Plan your hybrid Azure Active Directory join implementation
 Manage device identities using the Azure portal
9/7/2020 • 7 minutes to read • Edit Online

Azure AD provides you with a central place to manage device identities.

1. Sign in to the Azure portal.
2. Browse to Azure Active Director y > Devices .

The All devices page enables you to:

Identify devices, including:
Devices that have been joined or registered in Azure AD.
Devices deployed using Windows Autopilot.
Printers using Universal Print
Perform device identity management tasks like enable, disable, delete, or manage.
Printers and Windows Autopilot devices have limited management options in Azure AD. They must be
managed from their respective admin interfaces.
Configure your device identity settings.
Enable or disable Enterprise State Roaming.
Review device-related audit logs

Manage devices
There are two locations to manage devices in Azure AD:
Azure por tal > Azure Active Director y > Devices
Azure por tal > Azure Active Director y > Users > Select a user > Devices
Both options allow administrators the ability to:
 Search for devices.
See device details including:
Device name
Device ID
OS and Version
Join type
Owner
Mobile device management and compliance
BitLocker recovery key
Perform device identity management tasks like, enable, disable, delete, or manage.
Printers and Windows Autopilot devices have limited management options in Azure AD. They must be
managed from their respective admin interfaces.

TIP
Hybrid Azure AD Joined Windows 10 devices do not have an owner. If you are looking for a device by owner and
didn't find it, search by the device ID.
If you see a device that is "Hybrid Azure AD joined" with a state "Pending" under the REGISTERED column, it
indicates that the device has been synchronized from Azure AD connect and is waiting to complete registration
from the client. Read more on how to plan your Hybrid Azure AD join implementation. Additional information can
be found in the article, Devices frequently asked questions.
For some iOS devices, the device names containing apostrophes can potentially use different characters that look
like apostrophes. So searching for such devices is a little tricky - if you are not seeing search results correctly,
ensure that the search string contains matching apostrophe character.

Manage an Intune device

If you are an Intune administrator, you can manage devices where MDM is marked Microsoft Intune . If the
device is not enrolled with Microsoft Intune, the "Manage" option will be greyed out.
Enable or disable an Azure AD device
To enable or disable devices, you have two options:
The toolbar on the All devices page after selecting one or more devices.
The toolbar after drilling down into a specific device.

IMPORTANT
You must be a global administrator or cloud device administrator in Azure AD to enable or disable a device.
Disabling a device prevents a device from successfully authenticating with Azure AD, thereby preventing the device
from accessing your Azure AD resources that are protected by device-based Conditional Access or using Windows
Hello for Business credentials.
Disabling a device will revoke both the Primary Refresh Token (PRT) and any Refresh Tokens (RT) on the device.
Printers cannot be enabled or disabled in Azure AD.

Delete an Azure AD device

To delete a device, you have two options:
The toolbar on the All devices page after selecting one or more devices.
The toolbar after drilling down into a specific device.
 IMPORTANT
You must be assigned the cloud device administrator, Intune administrator, or global administrator role in Azure AD to
delete a device.
Printers and Windows Autopilot devices cannot be deleted in Azure AD
Deleting a device:
Prevents a device from accessing your Azure AD resources.
Removes all details that are attached to the device, for example, BitLocker keys for Windows devices.
Represents a non-recoverable activity and is not recommended unless it is required.

If a device is managed by another management authority (for example, Microsoft Intune), make sure that the
device has been wiped / retired before deleting the device in Azure AD. Review how to manage stale devices
before deleting any devices.
View or copy device ID
You can use a device ID to verify the device ID details on the device or using PowerShell during troubleshooting.
To access the copy option, click the device.

View or copy BitLocker keys

You can view and copy the BitLocker keys to allow users to recover encrypted drives. These keys are only
available for Windows devices that are encrypted and have their keys stored in Azure AD. You can find these
keys when accessing details of a device by selecting Show Recover y Key . Selecting Show Recover y Key will
generate an audit log, which you can find in the KeyManagement category.
To view or copy the BitLocker keys, you need to be either the owner of the device, or a user that has at least one
of the following roles assigned:
Cloud Device Administrator
Global Administrator
Helpdesk Administrator
Intune Service Administrator
Security Administrator
Security Reader
Device list filtering (preview)
Previously, you could only filter the devices list by activity and enabled state. This preview now allows you to
filter the devices list by the following attributes on a device:
Enabled state
Compliant state
Join type (Azure AD joined, Hybrid Azure AD joined, Azure AD registered)
Activity timestamp
OS
Device type (Printers, Secure VMs, Shared devices, Registered devices)
To enable the preview filtering functionality in the All devices view:
1. Sign in to the Azure portal.
2. Browse to Azure Active Director y > Devices .
3. Select the banner that says, Tr y out the new devices filtering improvements. Click to enable the
preview.
You will now have the ability to Add filters to your All devices view.

Configure device settings

To manage device identities using the Azure AD portal, those devices need to be either registered or joined to
Azure AD. As an administrator, you can control the process of registering and joining devices by configuring the
following device settings.

Users may join devices to Azure AD - This setting enables you to select the users who can register their
devices as Azure AD joined devices. The default is All .

NOTE
Users may join devices to Azure AD setting is only applicable to Azure AD join on Windows 10.
 Additional local administrators on Azure AD joined devices - You can select the users that are
granted local administrator rights on a device. These users are added to the Device Administrators role in
Azure AD. Global administrators in Azure AD and device owners are granted local administrator rights by
default. This option is a premium edition capability available through products such as Azure AD Premium or
the Enterprise Mobility Suite (EMS).
Users may register their devices with Azure AD - You need to configure this setting to allow Windows
10 personal, iOS, Android, and macOS devices to be registered with Azure AD. If you select None , devices are
not allowed to register with Azure AD. Enrollment with Microsoft Intune or Mobile Device Management
(MDM) for Office 365 requires registration. If you have configured either of these services, ALL is selected
and NONE is not available.
Require Multi-Factor Auth to join devices - You can choose whether users are required to provide an
additional authentication factor to join their device to Azure AD. The default is No . We recommend requiring
multi-factor authentication when registering a device. Before you enable multi-factor authentication for this
service, you must ensure that multi-factor authentication is configured for the users that register their
devices. For more information on different Azure multi-factor authentication services, see getting started
with Azure multi-factor authentication.

NOTE
Require Multi-Factor Auth to join devices setting applies to devices that are either Azure AD joined or Azure AD
registered. This setting does not apply to hybrid Azure AD joined devices.

Maximum number of devices - This setting enables you to select the maximum number of Azure AD
joined or Azure AD registered devices that a user can have in Azure AD. If a user reaches this quota, they are
not be able to add additional devices until one or more of the existing devices are removed. The default value
is 50 .

NOTE
Maximum number of devices setting applies to devices that are either Azure AD joined or Azure AD registered. This
setting does not apply to hybrid Azure AD joined devices.

Enterprise State Roaming

Audit logs
Device activities are available through the activity logs. These logs include activities triggered by the device
registration service and by users:
Device creation and adding owners / users on the device
Changes to device settings
Device operations such as deleting or updating a device
Your entry point to the auditing data is Audit logs in the Activity section of the Devices page.
The audit log has a default list view that shows:
The date and time of the occurrence
The targets
The initiator / actor (who) of an activity
The activity (what)
You can customize the list view by clicking Columns in the toolbar.

To narrow down the reported data to a level that works for you, you can filter the audit data using the following
fields:
Category
Activity resource type
Activity
Date range
Target
Initiated By (Actor)
In addition to the filters, you can search for specific entries.

Next steps
How to manage stale devices in Azure AD
Enterprise State Roaming
 How To: Manage stale devices in Azure AD
9/7/2020 • 8 minutes to read • Edit Online

Ideally, to complete the lifecycle, registered devices should be unregistered when they are not needed anymore.
However, due to, for example, lost, stolen, broken devices, or OS reinstallations you typically have stale devices in
your environment. As an IT admin, you probably want a method to remove stale devices, so that you can focus
your resources on managing devices that actually require management.
In this article, you learn how to efficiently manage stale devices in your environment.

What is a stale device?

A stale device is a device that has been registered with Azure AD but has not been used to access any cloud apps
for a specific timeframe. Stale devices have an impact on your ability to manage and support your devices and
users in the tenant because:
Duplicate devices can make it difficult for your helpdesk staff to identify which device is currently active.
An increased number of devices creates unnecessary device writebacks increasing the time for Azure AD
connect syncs.
As a general hygiene and to meet compliance, you may want to have a clean state of devices.
Stale devices in Azure AD can interfere with the general lifecycle policies for devices in your organization.

Detect stale devices

Because a stale device is defined as registered device that hasn't been used to access any cloud apps for a specific
timeframe, detecting stale devices requires a timestamp-related property. In Azure AD, this property is called
ApproximateLastLogonTimestamp or activity timestamp . If the delta between now and the value of the
activity timestamp exceeds the timeframe you have defined for active devices, a device is considered to be
stale. This activity timestamp is now in public preview.

How is the value of the activity timestamp managed?

The evaluation of the activity timestamp is triggered by an authentication attempt of a device. Azure AD evaluates
the activity timestamp when:
A Conditional Access policies requiring managed devices or approved client apps has been triggered.
Windows 10 devices that are either Azure AD joined or hybrid Azure AD joined are active on the network.
Intune managed devices have checked in to the service.
If the delta between the existing value of the activity timestamp and the current value is more than 14 days (+/-5
day variance), the existing value is replaced with the new value.

How do I get the activity timestamp?

You have two options to retrieve the value of the activity timestamp:
The Activity column on the devices page in the Azure portal
 The Get-AzureADDevice cmdlet

Plan the cleanup of your stale devices

To efficiently clean up stale devices in your environment, you should define a related policy. This policy helps you
to ensure that you capture all considerations that are related to stale devices. The following sections provide you
with examples for common policy considerations.
Cleanup account
To update a device in Azure AD, you need an account that has one of the following roles assigned:
Global Administrator
Cloud Device Administrator
Intune Service Administrator
In your cleanup policy, select accounts that have the required roles assigned.
Timeframe
Define a timeframe that is your indicator for a stale device. When defining your timeframe, factor the window
noted for updating the activity timestamp into your value. For example, you shouldn't consider a timestamp that
is younger than 21 days (includes variance) as an indicator for a stale device. There are scenarios that can make a
device look like stale while it isn't. For example, the owner of the affected device can be on vacation or on a sick
leave. that exceeds your timeframe for stale devices.
Disable devices
It is not advisable to immediately delete a device that appears to be stale because you can't undo a deletion in the
case of false positives. As a best practice, disable a device for a grace period before deleting it. In your policy,
define a timeframe to disable a device before deleting it.
MDM -controlled devices
If your device is under control of Intune or any other MDM solution, retire the device in the management system
before disabling or deleting it.
System-managed devices
Don't delete system-managed devices. These are generally devices such as Autopilot. Once deleted, these devices
can't be reprovisioned. The new Get-AzureADDevice cmdlet excludes system-managed devices by default.
Hybrid Azure AD joined devices
Your hybrid Azure AD joined devices should follow your policies for on-premises stale device management.
To cleanup Azure AD:
Windows 10 devices - Disable or delete Windows 10 devices in your on-premises AD, and let Azure AD
Connect synchronize the changed device status to Azure AD.
Windows 7/8 - Disable or delete Windows 7/8 devices in your on-premises AD first. You can't use Azure AD
Connect to disable or delete Windows 7/8 devices in Azure AD. Instead, when you make the change in your
on-premises, you must disable/delete in Azure AD.

NOTE
Deleting devices in your on-premises AD or Azure AD does not remove registration on the client. It will only prevent
access to resources using device as an identity (e.g. Conditional Access). Read additional information on how to remove
registration on the client.
Deleting a Windows 10 device only in Azure AD will re-synchronize the device from your on-premises using Azure AD
connect but as a new object in "Pending" state. A re-registration is required on the device.
Removing the device from sync scope for Windows 10/Server 2016 devices will delete the Azure AD device. Adding it
back to sync scope will place a new object in "Pending" state. A re-registration of the device is required.
If you not using Azure AD Connect for Windows 10 devices to synchronize (e.g. ONLY using AD FS for registration), you
must manage lifecycle similar to Windows 7/8 devices.

Azure AD joined devices

Disable or delete Azure AD joined devices in the Azure AD.

NOTE
Deleting an Azure AD device does not remove registration on the client. It will only prevent access to resources using
device as an identity (e.g Conditional Access).
Read more on how to unjoin on Azure AD

Azure AD registered devices

Disable or delete Azure AD registered devices in the Azure AD.

NOTE
Deleting an Azure AD registered device in Azure AD does not remove registration on the client. It will only prevent
access to resources using device as an identity (e.g. Conditional Access).
Read more on how to remove a registration on the client

Clean up stale devices in the Azure portal

While you can cleanup stale devices in the Azure portal, it is more efficient, to handle this process using a
PowerShell script. Use the latest PowerShell V1 module to use the timestamp filter and to filter out system-
managed devices such as Autopilot. At this point, using PowerShell V2 is not recommended.
A typical routine consists of the following steps:
1. Connect to Azure Active Directory using the Connect-AzureAD cmdlet
2. Get the list of devices
3. Disable the device using the Set-AzureADDevice cmdlet (disable by using -AccountEnabled option).
4. Wait for the grace period of however many days you choose before deleting the device.
5. Remove the device using the Remove-AzureADDevice cmdlet.
Get the list of devices
To get all devices and store the returned data in a CSV file:

Get-AzureADDevice -All:$true | select-object -Property Enabled, DeviceId, DisplayName, DeviceTrustType,

ApproximateLastLogonTimestamp | export-csv devicelist-summary.csv

If you have a large number of devices in your directory, use the timestamp filter to narrow down the number of
returned devices. To get all devices with a timestamp older than specific date and store the returned data in a CSV
file:

$dt = [datetime]’2017/01/01’
Get-AzureADDevice | Where {$_.ApproximateLastLogonTimeStamp -le $dt} | select-object -Property Enabled,
DeviceId, DisplayName, DeviceTrustType, ApproximateLastLogonTimestamp | export-csv devicelist-olderthan-Jan-
1-2017-summary.csv

What you should know

Why is the timestamp not updated more frequently?
The timestamp is updated to support device lifecycle scenarios. This is not an audit. Use the sign-in audit logs for
more frequent updates on the device.
Why should I worry about my BitLocker keys?
When configured, BitLocker keys for Windows 10 devices are stored on the device object in Azure AD. If you
delete a stale device, you also delete the BitLocker keys that are stored on the device. You should determine
whether your cleanup policy aligns with the actual lifecycle of your device before deleting a stale device.
Why should I worry about Windows Autopilot devices?
When you delete an Azure AD device that was associated with a Windows Autopilot object the following three
scenarios can occur if the device will be repurposed in future:
With Windows Autopilot user-driven deployments without using white glove, a new Azure AD device will be
created, but it won’t be tagged with the ZTDID.
With Windows Autopilot self-deploying mode deployments, they will fail because an associate Azure AD
device cannot be found. (This is a security mechanism to make sure that no “imposter” devices try to join
Azure AD with no credentials.) The failure will indicate a ZTDID mismatch.
With Windows Autopilot white glove deployments, they will fail because an associated Azure AD device cannot
be found. (Behind the scenes, white glove deployments use the same self-deploying mode process, so they
enforce the same security mechanisms.)
How do I know all the type of devices joined?
To learn more about the different types, see the device management overview.
What happens when I disable a device?
Any authentication where a device is being used to authenticate to Azure AD are denied. Common examples are:
Hybrid Azure AD joined device - Users might be able to use the device to sign-in to their on-premises
domain. However, they can't access Azure AD resources such as Office 365.
Azure AD joined device - Users can't use the device to sign in.
Mobile devices - User can't access Azure AD resources such as Office 365.
Next steps
To get an overview of how to manage device in the Azure portal, see managing devices using the Azure portal
 Enable Enterprise State Roaming in Azure Active
Directory
9/7/2020 • 4 minutes to read • Edit Online

Enterprise State Roaming is available to any organization with an Azure AD Premium or Enterprise Mobility +
Security (EMS) license. For more information on how to get an Azure AD subscription, see the Azure AD product
page.
When you enable Enterprise State Roaming, your organization is automatically granted a free, limited-use license
for Azure Rights Management protection from Azure Information Protection. This free subscription is limited to
encrypting and decrypting enterprise settings and application data synced by Enterprise State Roaming. You must
have a paid subscription to use the full capabilities of the Azure Rights Management service.

NOTE
This article applies to the Microsoft Edge Legacy HTML-based browser launched with Windows 10 in July 2015. The article
does not apply to the new Microsoft Edge Chromium-based browser released on January 15, 2020. For more information
on the Sync behavior for the new Microsoft Edge, see the article Microsoft Edge Sync.

To enable Enterprise State Roaming

1. Sign in to Azure AD admin center.
2. Select Azure Active Director y > Devices > Enterprise State Roaming .
3. Select Users may sync settings and app data across devices . For more information, see how to
configure device settings.

For a Windows 10 device to use the Enterprise State Roaming service, the device must authenticate using an Azure
AD identity. For devices that are joined to Azure AD, the user’s primary sign-in identity is their Azure AD identity, so
no additional configuration is required. For devices that use on-premises Active Directory, the IT admin must
Configure hybrid Azure Active Directory joined devices.

Data storage
Enterprise State Roaming data is hosted in one or more Azure regions that best align with the country/region
value set in the Azure Active Directory instance. Enterprise State Roaming data is partitioned based on three major
geographic regions: North America, EMEA, and APAC. Enterprise State Roaming data for the tenant is locally
located with the geographical region, and is not replicated across regions. For example:

C O UN T RY / REGIO N VA L UE H A S T H EIR DATA H O ST ED IN

An EMEA country/region such as France or Zambia One or more of the Azure regions within Europe

A North American country/region such as United States or One or more of the Azure regions within the US
Canada

An APAC country/region such as Australia or New Zealand One or more of the Azure regions within Asia

South American and Antarctica regions One or more Azure regions within the US

The country/region value is set as part of the Azure AD directory creation process and cannot be subsequently
modified. If you need more details on your data storage location, file a ticket with Azure support.

View per-user device sync status

Follow these steps to view a per-user device sync status report.
1. Sign in to Azure AD admin center.
2. Select Azure Active Director y > Users > All users .
3. Select the user, and then select Devices .
4. Under Show , select Devices syncing settings and app data to show sync status.

5. If there are devices syncing for this user, you see the devices as shown here.

Data retention
Data synced to the Microsoft cloud using Enterprise State Roaming is retained until it is manually deleted or until
the data in question is determined to be stale.
Explicit deletion
Explicit deletion is when an Azure admin deletes a user or a directory or otherwise requests explicitly that data is
to be deleted.
User deletion : When a user is deleted in Azure AD, the user account roaming data is deleted after 90 to 180
days.
 Director y deletion : Deleting an entire directory in Azure AD is an immediate operation. All the settings data
associated with that directory is deleted after 90 to 180 days.
On request deletion : If the Azure AD admin wants to manually delete a specific user’s data or settings data,
the admin can file a ticket with Azure support.
Stale data deletion
Data that has not been accessed for one year (“the retention period”) will be treated as stale and may be deleted
from the Microsoft cloud. The retention period is subject to change but will not be less than 90 days. The stale data
may be a specific set of Windows/application settings or all settings for a user. For example:
If no devices access a particular settings collection (for example, an application is removed from the device, or a
settings group such as “Theme” is disabled for all of a user’s devices), then that collection becomes stale after
the retention period and may be deleted.
If a user has turned off settings sync on all their devices, then none of the settings data will be accessed, and all
the settings data for that user will become stale and may be deleted after the retention period.
If the Azure AD directory admin turns off Enterprise State Roaming for the entire directory, then all users in that
directory will stop syncing settings, and all settings data for all users will become stale and may be deleted after
the retention period.
Deleted data recovery
The data retention policy is not configurable. Once the data is permanently deleted, it is not recoverable. However,
The settings data is deleted only from the Microsoft cloud, not from the end-user device. If any device later
reconnects to the Enterprise State Roaming service, the settings are again synced and stored in the Microsoft
cloud.

Next steps
Enterprise State Roaming overview
Settings and data roaming FAQ
Group Policy and MDM settings for settings sync
Windows 10 roaming settings reference
Troubleshooting
 Sign in to Windows virtual machine in Azure using
Azure Active Directory authentication (Preview)
9/7/2020 • 16 minutes to read • Edit Online

Organizations can now utilize Azure Active Directory (AD) authentication for their Azure virtual machines (VMs)
running Windows Ser ver 2019 Datacenter edition or Windows 10 1809 and later. Using Azure AD to
authenticate to VMs provides you with a way to centrally control and enforce policies. Tools like Azure role-based
access control (Azure RBAC) and Azure AD Conditional Access allow you to control who can access a VM. This
article shows you how to create and configure a Windows Server 2019 VM to use Azure AD authentication.

NOTE
Azure AD sign in for Azure Windows VMs is a public preview feature of Azure Active Directory. For more information about
previews, see Supplemental Terms of Use for Microsoft Azure Previews.

There are many benefits of using Azure AD authentication to log in to Windows VMs in Azure, including:
Utilize the same federated or managed Azure AD credentials you normally use.
No longer have to manage local administrator accounts.
Azure RBAC allows you to grant the appropriate access to VMs based on need and remove it when it is no
longer needed.
Before allowing access to a VM, Azure AD Conditional Access can enforce additional requirements such as:
Multi-factor authentication
Sign-in risk check
Automate and scale Azure AD join of Azure Windows VMs that are part for your VDI deployments.

NOTE
Once you enable this capability, your Windows VMs in Azure will be Azure AD joined. You cannot join it to other domain like
on-premises AD or Azure AD DS. If you need to do so, you will need to disconnect the VM from your Azure AD tenant by
uninstalling the extension.

Requirements
Supported Azure regions and Windows distributions
The following Windows distributions are currently supported during the preview of this feature:
Windows Server 2019 Datacenter
Windows 10 1809 and later

IMPORTANT
Remote connection to VMs joined to Azure AD is only allowed from Windows 10 PCs that are Azure AD joined or hybrid
Azure AD joined to the same directory as the VM.

The following Azure regions are currently supported during the preview of this feature:
 All Azure global regions

IMPORTANT
To use this preview feature, only deploy a supported Windows distribution and in a supported Azure region. The feature is
currently not supported in Azure Government or sovereign clouds.

Network requirements
To enable Azure AD authentication for your Windows VMs in Azure, you need to ensure your VMs network
configuration permits outbound access to the following endpoints over TCP port 443:
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
https://device.login.microsoftonline.com
https://pas.windows.net

Enabling Azure AD login in for Windows VM in Azure

To use Azure AD login in for Windows VM in Azure, you need to first enable Azure AD login option for your
Windows VM and then you need to configure Azure role assignments for users who are authorized to login in to
the VM. There are multiple ways you can enable Azure AD login for your Windows VM:
Using the Azure portal experience when creating a Windows VM
Using the Azure Cloud Shell experience when creating a Windows VM or for an existing Windows VM
Using Azure portal create VM experience to enable Azure AD login
You can enable Azure AD login for Windows Server 2019 Datacenter or Windows 10 1809 and later VM images.
To create a Windows Server 2019 Datacenter VM in Azure with Azure AD logon:
1. Sign in to the Azure portal, with an account that has access to create VMs, and select + Create a resource .
2. Type Windows Ser ver in Search the Marketplace search bar.
a. Click Windows Ser ver and choose Windows Ser ver 2019 Datacenter from Select a software plan
dropdown.
b. Click on Create .
3. On the "Management" tab, enable the option to Login with AAD credentials (Preview) under the Azure
Active Directory section from Off to On .
4. Make sure System assigned managed identity under the Identity section is set to On . This action should
happen automatically once you enable Login with Azure AD credentials.
5. Go through the rest of the experience of creating a virtual machine. During this preview, you will have to create
an administrator username and password for the VM.
 NOTE
In order to log in to the VM using your Azure AD credential, you will first need to configure role assignments for the VM as
described in one of the sections below.

Using the Azure Cloud Shell experience to enable Azure AD login

Azure Cloud Shell is a free, interactive shell that you can use to run the steps in this article. Common Azure tools
are preinstalled and configured in Cloud Shell for you to use with your account. Just select the Copy button to copy
the code, paste it in Cloud Shell, and then press Enter to run it. There are a few ways to open Cloud Shell:
Select Try It in the upper-right corner of a code block. Open Cloud Shell in your browser. Select the Cloud Shell
button on the menu in the upper-right corner of the Azure portal.
If you choose to install and use the CLI locally, this article requires that you are running the Azure CLI version
2.0.31 or later. Run az --version to find the version. If you need to install or upgrade, see the article Install Azure
CLI.
1. Create a resource group with az group create.
2. Create a VM with az vm create using a supported distribution in a supported region.
3. Install the Azure AD login VM extension.
The following example deploys a VM named myVM that uses Win2019Datacenter, into a resource group named
myResourceGroup, in the southcentralus region. In the following examples, you can provide your own resource
group and VM names as needed.
 az group create --name myResourceGroup --location southcentralus

az vm create \
--resource-group myResourceGroup \
--name myVM \
--image Win2019Datacenter \
--assign-identity \
--admin-username azureuser \
--admin-password yourpassword

NOTE
It is required that you enable System assigned managed identity on your virtual machine before you install the Azure AD
login VM extension.

It takes a few minutes to create the VM and supporting resources.

Finally, install the Azure AD login VM extension to enable Azure AD login for Windows VM. VM extensions are
small applications that provide post-deployment configuration and automation tasks on Azure virtual machines.
Use az vm extension set to install the AADLoginForWindows extension on the VM named myVM in the
myResourceGroup resource group:

NOTE
You can install AADLoginForWindows extension on an existing Windows Server 2019 or Windows 10 1809 and later VM to
enable it for Azure AD authentication. An example of AZ CLI is shown below.

az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory \
--name AADLoginForWindows \
--resource-group myResourceGroup \
--vm-name myVM

The provisioningState of Succeeded is shown, once the extension is installed on the VM.

Configure role assignments for the VM

Now that you have created the VM, you need to configure Azure RBAC policy to determine who can log in to the
VM. Two Azure roles are used to authorize VM login:
Vir tual Machine Administrator Login : Users with this role assigned can log in to an Azure virtual machine
with administrator privileges.
Vir tual Machine User Login : Users with this role assigned can log in to an Azure virtual machine with
regular user privileges.

NOTE
To allow a user to log in to the VM over RDP, you must assign either the Virtual Machine Administrator Login or Virtual
Machine User Login role. An Azure user with the Owner or Contributor roles assigned for a VM do not automatically have
privileges to log in to the VM over RDP. This is to provide audited separation between the set of people who control virtual
machines versus the set of people who can access virtual machines.

There are multiple ways you can configure role assignments for VM:
 Using the Azure AD Portal experience
Using the Azure Cloud Shell experience
Using Azure AD Portal experience
To configure role assignments for your Azure AD enabled Windows Server 2019 Datacenter VMs:
1. Navigate to the specific virtual machine overview page
2. Select Access control (IAM) from the menu options
3. Select Add , Add role assignment to open the Add role assignment pane.
4. In the Role drop-down list, select a role such as Vir tual Machine Administrator Login or Vir tual Machine
User Login .
5. In the Select field, select a user, group, service principal, or managed identity. If you don't see the security
principal in the list, you can type in the Select box to search the directory for display names, email addresses,
and object identifiers.
6. Select Save , to assign the role.
After a few moments, the security principal is assigned the role at the selected scope.

Using the Azure Cloud Shell experience

The following example uses az role assignment create to assign the Virtual Machine Administrator Login role to
the VM for your current Azure user. The username of your active Azure account is obtained with az account show,
and the scope is set to the VM created in a previous step with az vm show. The scope could also be assigned at a
resource group or subscription level, and normal Azure RBAC inheritance permissions apply. For more
information, see Log in to a Linux virtual machine in Azure using Azure Active Directory authentication.
 username=$(az account show --query user.name --output tsv)
vm=$(az vm show --resource-group myResourceGroup --name myVM --query id -o tsv)

az role assignment create \

--role "Virtual Machine Administrator Login" \
--assignee $username \
--scope $vm

NOTE
If your AAD domain and logon username domain do not match, you must specify the object ID of your user account with
the --assignee-object-id , not just the username for --assignee . You can obtain the object ID for your user account
with az ad user list.

For more information on how to use Azure RBAC to manage access to your Azure subscription resources, see the
following articles:
Add or remove Azure role assignments using Azure CLI
Add or remove Azure role assignments using the Azure portal
Add or remove Azure role assignments using Azure PowerShell.

Using Conditional Access

You can enforce Conditional Access policies such as multi-factor authentication or user sign-in risk check before
authorizing access to Windows VMs in Azure that are enabled with Azure AD sign in. To apply Conditional Access
policy, you must select "Azure Windows VM Sign-In" app from the cloud apps or actions assignment option and
then use Sign-in risk as a condition and/or require multi-factor authentication as a grant access control.

NOTE
If you use "Require multi-factor authentication" as a grant access control for requesting access to the "Azure Windows VM
Sign-In" app, then you must supply multi-factor authentication claim as part of the client that initiates the RDP session to
the target Windows VM in Azure. The only way to achieve this on a Windows 10 client is to use Windows Hello for Business
PIN or biometric authentication with the RDP client. Support for biometric authentication was added to the RDP client in
Windows 10 version 1809. Remote desktop using Windows Hello for Business authentication is only available for
deployments that use cert trust model and currently not available for key trust model.

WARNING
Per-user Enabled/Enforced Azure Multi-Factor Authentication is not supported for VM sign-in.

Log in using Azure AD credentials to a Windows VM

IMPORTANT
Remote connection to VMs joined to Azure AD is only allowed from Windows 10 PCs that are either Azure AD registered
(minimum required build is 20H1) or Azure AD joined or hybrid Azure AD joined to the same directory as the VM.
Additionally, to RDP using Azure AD credentials, the user must belong to one of the two Azure roles, Virtual Machine
Administrator Login or Virtual Machine User Login. If using an Azure AD registered Windows 10 PC, you must enter
credentials in the AzureAD\UPN format (e.g. AzureAD\[email protected]). At this time, Azure Bastion can't be used to log in
by using Azure Active Directory authentication with the AADLoginForWindows extension; only direct RDP is supported.
To log in to your Windows Server 2019 virtual machine using Azure AD:
1. Navigate to the overview page of the virtual machine that has been enabled with Azure AD logon.
2. Select Connect to open the Connect to virtual machine blade.
3. Select Download RDP File .
4. Select Open to launch the Remote Desktop Connection client.
5. Select Connect to launch the Windows logon dialog.
6. Logon using your Azure AD credentials.
You are now signed in to the Windows Server 2019 Azure virtual machine with the role permissions as assigned,
such as VM User or VM Administrator.

NOTE
You can save the .RDP file locally on your computer to launch future remote desktop connections to your virtual machine
instead of having to navigate to virtual machine overview page in the Azure portal and using the connect option.

Troubleshoot
Troubleshoot deployment issues
The AADLoginForWindows extension must install successfully in order for the VM to complete the Azure AD join
process. Perform the following steps if the VM extension fails to install correctly.
1. RDP to the VM using the local administrator account and examine the CommandExecuti'n.log under
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\0.3.1.0.

NOTE
If the extension restarts after the initial failure, the log with the deployment error will be saved as
CommandExecution_YYYYMMDDHHMMSSSSS.log. "

2. Open a command prompt on the VM and verify these queries against the Instance Metadata Service (IMDS)
Endpoint running on the Azure host returns:

C O M M A N D TO RUN EXP EC T ED O UT P UT

curl -H @{"Metadata"="true"} Correct information about the Azure VM

"http://169.254.169.254/metadata/instance?api-
version=2017-08-01"

curl -H @{"Metadata"="true"} Valid Tenant ID associated with the Azure Subscription

"http://169.254.169.254/metadata/identity/info?
api-version=2018-02-01"

curl -H @{"Metadata"="true"} Valid access token issued by Azure Active Directory for the
"http://169.254.169.254/metadata/identity/oauth2/token?managed identity that is assigned to this VM
resource=urn:ms-
drs:enterpriseregistration.windows.net&api-
version=2018-02-01"

NOTE
The access token can be decoded using a tool like http://calebb.net/. Verify the "appid" in the access token matches
the managed identity assigned to the VM.
3. Ensure the required endpoints are accessible from the VM using the command line:
curl https://login.microsoftonline.com/ -D –
curl https://login.microsoftonline.com/ <TenantID> / -D –

NOTE
Replace <TenantID> with the Azure AD Tenant ID that is associated with the Azure subscription.

curl https://enterpriseregistration.windows.net/ -D -
curl https://device.login.microsoftonline.com/ -D -
curl https://pas.windows.net/ -D -
4. The Device State can be viewed by running dsregcmd /status . The goal is for Device State to show as
AzureAdJoined : YES .

NOTE
Azure AD join activity is captured in Event viewer under the User Device Registration\Admin log.

If AADLoginForWindows extension fails with certain error code, you can perform the following steps:
Issue 1: AADLoginForWindows extension fails to install with terminal error code '1007' and Exit code: -2145648574.
This exit code translates to DSREG_E_MSI_TENANTID_UNAVAILABLE because the extension is unable to query the
Azure AD Tenant information.
1. Verify the Azure VM can retrieve the TenantID from the Instance Metadata Service.
RDP to the VM as a local administrator and verify the endpoint returns valid Tenant ID by running
this command from an elevated command line on the VM:
curl -H Metadata:true http://169.254.169.254/metadata/identity/info?api-version=2018-02-01
2. The VM admin attempts to install the AADLoginForWindows extension, but a system assigned managed
identity has not enabled the VM first. Navigate to the Identity blade of the VM. From the System assigned
tab, verify Status is toggled to On.
Issue 2: AADLoginForWindows extension fails to install with Exit code: -2145648607
This Exit code translates to DSREG_AUTOJOIN_DISC_FAILED because the extension is not able to reach the
https://enterpriseregistration.windows.net endpoint.

1. Verify the required endpoints are accessible from the VM using the command line:
curl https://login.microsoftonline.com/ -D –
curl https://login.microsoftonline.com/ <TenantID> / -D –

NOTE
Replace <TenantID> with the Azure AD Tenant ID that is associated with the Azure subscription. If you need to find
the tenant ID, you can hover over your account name to get the directory / tenant ID, or select Azure Active
Directory > Properties > Directory ID in the Azure portal.

curl https://enterpriseregistration.windows.net/ -D -
curl https://device.login.microsoftonline.com/ -D -
curl https://pas.windows.net/ -D -
2. If any of the commands fails with "Could not resolve host <URL> ", try running this command to determine
 the DNS server that is being used by the VM.
nslookup <URL>

NOTE
Replace <URL> with the fully qualified domain names used by the endpoints, such as "login.microsoftonline.com".

3. Next, see if specifying a public DNS server allows the command to succeed:
nslookup <URL> 208.67.222.222

4. If necessary, change the DNS server that is assigned to the network security group that the Azure VM
belongs to.
Issue 3: AADLoginForWindows extension fails to install with Exit code: 51
Exit code 51 translates to "This extension is not supported on the VM's operating system".
At Public Preview, the AADLoginForWindows extension is only intended to be installed on Windows Server 2019
or Windows 10 (Build 1809 or later). Ensure the version of Windows is supported. If the build of Windows is not
supported, uninstall the VM Extension.
Troubleshoot sign-in issues
Some common errors when you try to RDP with Azure AD credentials include no Azure roles assigned,
unauthorized client, or 2FA sign-in method required. Use the following information to correct these issues.
The Device and SSO State can be viewed by running dsregcmd /status . The goal is for Device State to show as
AzureAdJoined : YES and SSO State to show AzureAdPrt : YES .

Also, RDP Sign-in using Azure AD accounts is captured in Event viewer under the AAD\Operational event logs.
Azure role not assigned
If you see the following error message when you initiate a remote desktop connection to your VM:
Your account is configured to prevent you from using this device. For more info, contact your system
administrator

Verify that you have configured Azure RBAC policies for the VM that grants the user either the Virtual Machine
Administrator Login or Virtual Machine User Login role:
Unauthorized client
If you see the following error message when you initiate a remote desktop connection to your VM:
Your credentials did not work

Verify that the Windows 10 PC you are using to initiate the remote desktop connection is one that is either Azure
AD joined, or hybrid Azure AD joined to the same Azure AD directory where your VM is joined to. For more
information about device identity, see the article What is a device identity.

NOTE
Windows 10 Build 20H1 added support for an Azure AD registered PC to initiate RDP connection to your VM. When using
an Azure AD registered (not Azure AD joined or hybrid Azure AD joined) PC as the RDP client to initiate connections to your
VM, you must enter credentials in the format AzureAD\UPn (e.g. AzureAD\[email protected]).

Also, verify the AADLoginForWindows extension has not been uninstalled after Azure AD join has completed.
MFA sign-in method required
If you see the following error message when you initiate a remote desktop connection to your VM:
The sign-in method you're trying to use isn't allowed. Try a different sign-in method or contact your system
administrator.
If you have configured a Conditional Access policy that requires multi-factor authentication (MFA) before you can
access the resource, then you need to ensure that the Windows 10 PC initiating the remote desktop connection to
your VM signs in using a strong authentication method such as Windows Hello. If you do not use a strong
authentication method for your remote desktop connection, you will see the previous error.
If you have not deployed Windows Hello for Business and if that is not an option for now, you can exclude MFA
requirement by configuring Conditional Access policy that excludes "Azure Windows VM Sign-In" app from the list
of cloud apps that require MFA. To learn more about Windows Hello for Business, see Windows Hello for Business
Overview.

NOTE
Windows Hello for Business PIN authentication with RDP has been supported by Windows 10 for several versions, however
support for Biometric authentication with RDP was added in Windows 10 version 1809. Using Windows Hello for Business
auth during RDP is only available for deployments that use cert trust model and currently not available for key trust model.

Preview feedback
Share your feedback about this preview feature or report issues using it on the Azure AD feedback forum.

Next steps
For more information on Azure Active Directory, see What is Azure Active Directory
 Device identity and desktop virtualization
9/7/2020 • 4 minutes to read • Edit Online

Administrators commonly deploy virtual desktop infrastructure (VDI) platforms hosting Windows operating
systems in their organizations. Administrators deploy VDI to:
Streamline management.
Reduce costs through consolidation and centralization of resources.
Deliver end-users mobility and the freedom to access virtual desktops anytime, from anywhere, on any device.
There are two primary types of virtual desktops:
Persistent
Non-persistent
Persistent versions use a unique desktop image for each user or a pool of users. These unique desktops can be
customized and saved for future use.
Non-persistent versions use a collection of desktops that users can access on an as needed basis. These non-
persistent desktops are reverted to their original state, in case of Windows current1 this happens when a virtual
machine goes through a shutdown/restart/OS reset process and in case of Windows down-level2 this happens
when a user signs out.
There has been a rise in non-persistent VDI deployments as remote work continues to be the new norm. As
customers deploy non-persistent VDI, it is important to ensure that you manage device churn that could be caused
due to frequent device registration without having a proper strategy for device lifecycle management.

IMPORTANT
Failure to manage device churn, can lead to pressure increase on your tenant quota usage consumption and potential risk of
service interruption, if you run out of tenant quota. You should follow the guidance documented below when deploying non
persistent VDI environments to avoid this situation.

This article will cover Microsoft's guidance to administrators on support for device identity and VDI. For more
information about device identity, see the article What is a device identity.

Supported scenarios
Before configuring device identities in Azure AD for your VDI environment, familiarize yourself with the supported
scenarios. The table below illustrates which provisioning scenarios are supported. Provisioning in this context
implies that an administrator can configure device identities at scale without requiring any end-user interaction.

DEVIC E IDEN T IT Y IDEN T IT Y VDI P L AT F O RM

TYPE IN F RA ST RUC T URE W IN DO W S DEVIC ES VERSIO N SUP P O RT ED

Hybrid Azure AD Federated3 Windows current and Persistent Yes

joined Windows down-level

Windows current Non-Persistent Yes5

Windows down-level Non-Persistent Yes6

 DEVIC E IDEN T IT Y IDEN T IT Y VDI P L AT F O RM
TYPE IN F RA ST RUC T URE W IN DO W S DEVIC ES VERSIO N SUP P O RT ED

Managed4 Windows current and Persistent Yes

Windows down-level

Windows current Non-Persistent No

Windows down-level Non-Persistent Yes6

Azure AD joined Federated Windows current Persistent No

Non-Persistent No

Managed Windows current Persistent No

Non-Persistent No

Azure AD registered Federated/Managed Windows Persistent/Non- Not Applicable

current/Windows Persistent
down-level

1 Windows current devices represent Windows 10, Windows Server 2016, and Windows Server 2019.
2 Windows down-level devices represent Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server
2012, and Windows Server 2012 R2. For support information on Windows 7, see Support for Windows 7 is
ending. For support information on Windows Server 2008 R2, see Prepare for Windows Server 2008 end of
support.
3 A Federated identity infrastructure environment represents an environment with an identity provider such as
AD FS or other third-party IDP.
4 A Managed identity infrastructure environment represents an environment with Azure AD as the identity
provider deployed with either password hash sync (PHS) or pass-through authentication (PTA) with seamless
single sign-on.
5 Non-Persistence suppor t for Windows current requires additional consideration as documented below in
guidance section. This scenario requires Windows 10 1803, Windows Server 2019 or Windows Server (Semi-
annual channel) starting version 1803
6 Non-Persistence suppor t for Windows down-level requires additional consideration as documented below
in guidance section.

Microsoft’s guidance
Administrators should reference the following articles, based on their identity infrastructure, to learn how to
configure hybrid Azure AD join.
Configure hybrid Azure Active Directory join for federated environment
Configure hybrid Azure Active Directory join for managed environment
When deploying non-persistent VDI, Microsoft recommends that IT administrators implement the guidance below.
Failure to do so will result in your directory having lots of stale Hybrid Azure AD joined devices that were
registered from your non-persistent VDI platform resulting in increased pressure on your tenant quota and risk of
service interruption due to running out of tenant quota.
 If you are relying on the System Preparation Tool (sysprep.exe) and if you are using a pre-Windows 10 1809
image for installation, make sure that image is not from a device that is already registered with Azure AD as
hybrid Azure AD joined.
If you are relying on a Virtual Machine (VM) snapshot to create additional VMs, make sure that snapshot is not
from a VM that is already registered with Azure AD as Hybrid Azure AD join.
Create and use a prefix for the display name (e.g. NPVDI-) of the computer that indicates the desktop as non-
persistent VDI-based.
For Windows down-level:
Implement autoworkplacejoin /leave command as part of logoff script. This command should be
triggered in the context of the user and should be execute before the user has logged off completely and
while there is still network connectivity.
For Windows current in a Federated environment (e.g. AD FS):
Implement dsregcmd /join as part of VM boot sequence.
DO NOT execute dsregcmd /leave as part of VM shutdown/restart process.
Define and implement process for managing stale devices.
Once you have a strategy to identify your non-persistent Hybrid Azure AD joined devices (e.g. using
computer display name prefix), you should be more aggressive on the clean-up of these devices to
ensure your directory does not get consumed with lots of stale devices.
For non-persistent VDI deployments on Windows current and down-level, you should delete devices that
have ApproximateLastLogonTimestamp of older than 15 days.

Next steps
Configuring hybrid Azure Active Directory join for federated environment
 Deploy a secure, Azure-managed workstation
9/7/2020 • 18 minutes to read • Edit Online

Now that you understand secure workstations, it's time to begin the process of deployment. With this guidance,
you use defined profiles to create a workstation that's more secure from the start.

Select a profile before deploying the solution. You can use multiple profiles simultaneously in a deployment and
assign them with tags or groups.

NOTE
Apply any of the profiles as needed by your requirements. You can move to another profile by assigning it in Microsoft
Intune.

SP EC IA L IZ E
P RO F IL E LO W EN H A N C ED H IGH D SEC URED ISO L AT ED

User in Yes Yes Yes Yes Yes Yes

Azure AD

Intune- Yes Yes Yes Yes Yes Yes

managed

Device - Yes
Azure AD
registered

Device - Yes Yes Yes Yes Yes

Azure AD
joined
 SP EC IA L IZ E
P RO F IL E LO W EN H A N C ED H IGH D SEC URED ISO L AT ED

Intune Yes Yes Yes Yes NA

security (Enhanced) (HighSecurit (NCSC) (Secured)
baseline y)
applied

Hardware Yes Yes Yes Yes Yes

meets
secure
Windows
10
Standards

Microsoft Yes Yes Yes Yes Yes

Defender
ATP
enabled

Removal of Yes Yes Yes Yes

admin
rights

Deploymen Yes Yes Yes Yes

t using
Microsoft
Autopilot

Apps Yes Yes Yes

installed
only by
Intune

URLs Yes Yes Yes

restricted to
approved
list

Internet Yes
blocked
(inbound/o
utbound)

NOTE
In the secure workstation guidance devices will be assigned with profiles and policies. Users will not have the policies applied
to them directly, allowing device sharing (shared devices) to be in effect. If a secure workstation is not shared in your
deployment, or individual user policies are needed, assignment of the user policy profiles can be assigned to the user and
device.

License requirements
The concepts covered in this guide assume you have Microsoft 365 Enterprise E5 or an equivalent SKU. Some of
the recommendations in this guide can be implemented with lower SKUs. For more information, see Microsoft 365
Enterprise licensing.
To automate license provisioning, consider group-based licensing for your users.

Azure Active Directory configuration

Azure Active Directory (Azure AD) manages users, groups, and devices for your administrator workstations. Enable
identity services and features with an administrator account.
When you create the secured workstation administrator account, you expose the account to your current
workstation. Make sure you use a known safe device to do this initial configuration and all global configuration. To
reduce the attack exposure for the first-time experience, consider following the guidance to prevent malware
infections.
Require multi-factor authentication, at least for your administrators. See Deploy cloud-based MFA for
implementation guidance.
Azure AD users and groups
1. From the Azure portal, browse to Azure Active Director y > Users > New user .
2. Create your device administrator by following the steps in the create user tutorial.
3. Enter:
Name - Secure Workstation Administrator
User name - [email protected]
Director y role - Limited administrator and select the Intune Administrator role.
4. Select Create .
Next, you create two groups: workstation users and workstation devices.
From the Azure portal, browse to Azure Active Director y > Groups > New group .
1. For the workstation users group, you might want to configure group-based licensing to automate
provisioning of licenses to users.
2. For the workstation users group, enter:
Group type - Security
Group name - Secure Workstation Users
Membership type - Assigned
3. Add your secure workstation administrator user: [email protected]

4. You can add any other users that will be managing secure workstations.
5. Select Create .
6. For the workstation devices group, enter:
Group type - Security
Group name - Secure Workstations
Membership type - Assigned
7. Select Create .
Azure AD device configuration
Specify who can join devices to Azure AD
Configure your devices setting in Active Directory to allow your administrative security group to join devices to
your domain. To configure this setting from the Azure portal:
1. Go to Azure Active Director y > Devices > Device settings .
2. Choose Selected under Users may join devices to Azure AD , and then select the "Secure Workstation
Users" group.
Removal of local admin rights
This method requires that users of the VIP, DevOps, and secure-level workstations have no administrator rights on
their machines. To configure this setting from the Azure portal:
1. Go to Azure Active Director y > Devices > Device settings .
2. Select None under Additional local administrators on Azure AD joined devices .
Require multi-factor authentication to join devices
To further strengthen the process of joining devices to Azure AD:
1. Go to Azure Active Director y > Devices > Device settings .
2. Select Yes under Require Multi-Factor Auth to join devices .
3. Select Save .
Configure mobile device management
From the Azure portal:
1. Browse to Azure Active Director y > Mobility (MDM and MAM) > Microsoft Intune .
2. Change the MDM user scope setting to All .
3. Select Save .
These steps allow you to manage any device with Intune. For more information, see Intune Quickstart: Set up
automatic enrollment for Windows 10 devices. You create Intune configuration and compliance policies in a future
step.
Azure AD Conditional Access
Azure AD Conditional Access can help restrict privileged administrative tasks to compliant devices. Predefined
members of the Secure Workstation Users group are required to perform multi-factor authentication when
signing in to cloud applications. A best practice is to exclude emergency access accounts from the policy. For more
information, see Manage emergency access accounts in Azure AD.

Intune configuration
Configure enrollment status
It's important to ensure that your secure workstation is a trusted clean device. When purchasing new devices, you
can insist that they're factory set to Windows 10 Pro in S mode, which limits exposure to vulnerabilities during
supply chain management. After you receive a device from your supplier, you can use Autopilot to change it from S
mode. The following guidance provides details on applying the transformation process.
To ensure that devices are fully configured before use, Intune provides a means to Block device use until all
apps and profiles are installed .
From the Azure por tal :
1. Go to Microsoft Intune > Device enrollment > Windows enrollment > Enrollment Status Page >
Default > Settings .
2. Set Show app profile installation progress to Yes .
3. Set Block device use until all apps and profiles are installed to Yes .
Create an Autopilot deployment profile
After creating a device group, you must create a deployment profile to configure the Autopilot devices.
In Intune in the Azure portal:
1. Select Device enrollment > Windows enrollment > Deployment Profiles > Create Profile .
2. Enter:
Name - Secure workstation deployment profile .
Description - Deployment of secure workstations .
Set Conver t all targeted devices to Autopilot to Yes . This setting makes sure that all devices in the
list get registered with the Autopilot deployment service. Allow 48 hours for the registration to be
processed.
3. Select Next .
For Deployment mode , choose Self-Deploying (Preview) . Devices with this profile are associated
with the user who enrolls the device. User credentials are required to enroll the device. It's essential to
note that deploying a device in the Self-Deploying mode will allow you to deploy laptops in a shared
model. No user assignment will happen until the device is assigned to a user for the first time. As a
result, any user policies such as BitLocker will not be enabled until a user assignment is completed. For
more information about how to log on to a secured device, see selected profiles.
The Join to Azure AD as box should show Azure AD joined and be grayed out.
Select your Language (Region), User account type standard .
4. Select Next .
Select a scope tag if you have preconfigured one.
5. Select Next .
6. Choose Assignments > Assign to > Selected Groups . In Select groups to include , choose Secure
Workstations .
7. Select Next .
8. Select Create to create the profile. The Autopilot deployment profile is now available to assign to devices.
Device enrollment in Autopilot provides a different user experience based on device type and role. In our
deployment example, we illustrate a model where the secured devices are bulk deployed and can be shared, but
when used for the first time, the device is assigned to a user. For more information, see Intune Autopilot device
enrollment.
Configure Windows Update
Keeping Windows 10 up to date is one of the most important things you can do. To maintain Windows in a secure
state, you deploy an update ring to manage the pace that updates are applied to workstations.
This guidance recommends that you create a new update ring and change the following default settings:
In the Azure portal:
1. Go to Microsoft Intune > Software updates > Windows 10 Update Rings .
2. Enter:
Name - Azure-managed workstation updates
Servicing channel - Windows Insider - Fast
Quality update deferral (days) - 3
Feature update deferral period (days) - 3
Automatic update behavior - Auto install and reboot without end-user control
Block user from pausing Windows updates - Block
Require user's approval to restart outside of work hours - Required
Allow user to restart (engaged restart) - Required
 Transition users to engaged restart after an auto-restart (days) - 3
Snooze engaged restart reminder (days) - 3
Set deadline for pending restarts (days) - 3
3. Select Create .
4. On the Assignments tab, add the Secure Workstations group.
For more information about Windows Update policies, see Policy CSP - Update.
Windows Defender ATP Intune integration
Windows Defender ATP and Microsoft Intune work together to help prevent security breaches. They can also limit
the impact of breaches. ATP capabilities provide real-time threat detection as well as enable extensive auditing and
logging of the end-point devices.
To configure integration of Windows Defender ATP and Intune, go to the Azure portal.
1. Browse to Microsoft Intune > Device compliance > Windows Defender ATP .
2. In step 1 under Configuring Windows Defender ATP , select Connect Windows Defender ATP to
Microsoft Intune in the Windows Defender Security Center .
3. In the Windows Defender Security Center:
a. Select Settings > Advanced features .
b. For Microsoft Intune connection , choose On .
c. Select Save preferences .
4. After a connection is established, return to Intune and select Refresh at the top.
5. Set Connect Windows devices version 10.0.15063 and above to Windows Defender ATP to On .
6. Select Save .
For more information, see Windows Defender Advanced Threat Protection.
Finish workstation profile hardening
To successfully complete the hardening of the solution, download and execute the appropriate script. Find the
download links for your desired profile level :

P RO F IL E DO W N LO A D LO C AT IO N F IL EN A M E

Low Security N/A N/A

Enhanced Security https://aka.ms/securedworkstationgit Enhanced-Workstation-Windows10-

(1809).ps1

High Security https://aka.ms/securedworkstationgit HighSecurityWorkstation-Windows10-

(1809).ps1

Specialized https://github.com/pelarsen/IntunePow DeviceConfiguration_NCSC -

erShellAutomation Windows10 (1803) SecurityBaseline.ps1

Specialized Compliance* https://aka.ms/securedworkstationgit DeviceCompliance_NCSC-

Windows10(1803).ps1

Secured https://aka.ms/securedworkstationgit Secure-Workstation-Windows10-

(1809)-SecurityBaseline.ps1
* Specialized Compliance is a script that enforces the Specialized configuration provided in the NCSC Windows10
SecurityBaseline.
After the script successfully executes, you can make updates to profiles and policies in Intune. The scripts for
Enhanced and Secure profiles create policies and profiles for you, but you must assign the policy to your Secure
Workstations device group.
Here's where you can find the Intune device configuration profiles created by the scripts: Azure por tal >
Microsoft Intune > Device configuration > Profiles .
Here's where you can find the Intune device compliance policies created by the scripts: Azure por tal >
Microsoft Intune > Device Compliance > Policies .
To review changes made by the scripts, you can export the profiles. This way you can determine additional
hardening that may be required as outlined in the SECCON documentation.
Run the Intune data export script DeviceConfiguration_Export.ps1 from the DeviceConfiguration GiuHub
repository to export all current Intune profiles.

Additional configurations and hardening to consider

By following the guidance here, you've deployed a secure workstation. However, you also should consider
additional controls. For example:
limit access to alternate browsers
allow outbound HTTP
block select websites
set permissions for running custom PowerShell scripts
Set rules in the firewall configuration service provider (CSP)
You can make additional changes to the management of both inbound and outbound rules as needed for your
permitted and blocked endpoints. As you continue to harden the secure workstation, you can loosen the restriction
that denies all inbound and outbound traffic. You might add permitted outbound sites to include common and
trusted websites. For more information, see Firewall configuration service.
Restrictive URL traffic management includes:
Deny All inbound traffic - Set in the Secured workstation profile script.
Deny All outbound except selected Azure and Microsoft services including Azure Cloud Shell and the ability to
allows Azure Password Reset.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"ProxyEnable"=dword:00000001
"ProxyServer"="127.0.0.1:80"
"ProxyOverride"="*.azure.com;*.azure.net;*.microsoft.com;*.windowsupdate.com;*.microsoftonline.com;*.microsoft
online.cn;*.windows.net;*.windowsazure.com;*.windowsazure.cn;*.azure.cn;*.loganalytics.io;*.applicationinsight
s.io;*.vsassets.io;*.azure-
automation.net;*.visualstudio.com,portal.office.com;*.aspnetcdn.com;*.sharepointonline.com;*.msecnd.net;*.msoc
dn.com;*.webtrends.com"
"AutoDetect"=dword:00000000

If you are looking to provide more granularity to your blocking rules, you can refer to the Spamhaus Project who
maintains the Domain Block List (DBL): a good resource to use as an advanced set of rules to implement for
blocking sites.
Manage local applications
The secure workstation moves to a truly hardened state when local applications are removed, including
 productivity applications. Here, you add Chrome as the default browser and use Intune to limit a user's ability to
modify the browser and its plug-ins.
Deploy applications using Intune
In some situations, applications like the Google Chrome browser are required on the secured workstation. The
following example provides instructions to install Chrome to devices in the security group Secure Workstations .
1. Download the offline installer Chrome bundle for Windows 64 bit.
2. Extract the files and make note of the location of the GoogleChromeStandaloneEnterprise64.msi file.
3. In the Azure por tal browse to Microsoft Intune > Client apps > Apps > Add .
4. Under App type , choose Line-of-business .
5. Under App package file , select the GoogleChromeStandaloneEnterprise64.msi file from the extracted location
and select OK .
6. Under App information , provide a description and a publisher. Select OK .
7. Select Add .
8. On the Assignments tab, select Available for enrolled devices under Assignment type .
9. Under Included Groups , add the Secure Workstations group.
10. Select OK , and then select Save .
For more information on configuring Chrome settings, see Manage Chrome Browser with Microsoft Intune.
Configuring the company portal for custom apps
In a secured mode, application installation is restricted to the Intune company portal. However, installing the portal
requires access to Microsoft Store. In your secured solution, you can make the company portal available to all
devices through an offline mode.
An Intune-managed copy of the Company Portal gives you on-demand access to additional tools that you can
push down to users of the secured workstations.
You might need to install Windows 32-bit apps or other apps whose deployment require special preparations. In
such cases, the Microsoft win32 content prep tool can provide a ready-to-use .intunewin format file for
installation.
Conditional Access only allowing secured workstation ability to access Azure portal
Azure AD offers the ability to manage and restrict, who and what can access your Azure cloud management portal.
Enabling Conditional Access will assure that only your secure workstation can manage or change resources. It's
essential that while deploying this feature you consider, if emergency access functionality can or should be used
only for extreme cases and the account managed through policy.

NOTE
You will need to create a user group, and include your emergency user that can bypass the Conditional Access policy. For our
example we have a security group called Emergency BreakGlass

1. Browse to the Azure por tal > Microsoft Intune > Conditional Access - Policies > New Policy .
2. Provide a Name for the policy.
3. Select User and Groups > Select users and groups
4. Select Include > Director y roles > Choose the roles > Global Administrator, Privileged Role Administrator,
Privileged Authentication Administrator, Security Administrator, Compliance Administrator, Conditional Access
Administrator, Application Administrator, Cloud Application Administrator, Intune Service Administrator
5. Select Exclude > Choose Users and groups > Select Select excluded users > Select your Emergency
BreakGlass group.
6. Select Cloud apps or actions > Select All cloud apps
7. Select Conditions > Select Device Platforms > Choose configure Yes > Select Select Device platforms
Choose Windows
8. Select Access controls > Select Grant Access Yes > Choose Require device to be marked as compliant .
9. Select Enable Policy > On
This policy set will ensure that your Administrators must use a compliant Windows device, which is set by Intune,
and WDATP.
Organizations should also consider blocking legacy authentication protocols in their environments. There are
multiple ways to accomplish this task, for more information about blocking legacy authentication protocols see the
article, How to: Block legacy authentication to Azure AD with Conditional Access.
Use PowerShell to create custom settings
You can also use PowerShell to extend host management capabilities. This example script sets up a default
background on the host. It's a capability that's also available through the Azure portal and profiles. The example
script serves only to illustrate the PowerShell functionality.
You might need to set up some custom controls and settings on your secure workstations. This example changes
the background of the workstation by using Powershell's ability to easily identify the device as a ready-to-use,
secure workstation.
The SetDesktopBackground.ps1 script from the Microsoft Scripting Center allows Windows to load this free,
generic background image on startup.
1. Download the script to a local device.
2. Update the customerXXXX and the download location of the background image. In our example, we replace
customerXXXX to backgrounds.
3. Browse to the Azure por tal > Microsoft Intune > Device configuration > PowerShell scripts > Add .
4. Provide a Name for the script and specify the Script location .
5. Select Configure .
a. Set Run this script using the logged on credentials to Yes .
b. Select OK .
6. Select Create .
7. Select Assignments > Select groups .
a. Add the security group Secure Workstations .
b. Select Save .

Enroll and validate your first device

1. To enroll your device, you need the following information:
Serial number - found on the device chassis.
Windows Product ID - found under System > About from the Windows Settings menu.
You can run Get-WindowsAutoPilotInfo to get a CSV hash file with all of the required information for
device enrollment.
Run Get-WindowsAutoPilotInfo – outputfile device1.csv to output the information as a CSV file that
you can import in to Intune.

NOTE
The script requires elevated rights. It runs as remote signed. The
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned command allows the script to run correctly.
 You can gather this information by signing in to a Windows 10 version 1809 or higher device. Your
hardware reseller can also provide this information.
2. In the Azure por tal , go to Microsoft Intune > Device enrollment > Windows enrollment > Devices -
Manage Windows Autopilot devices .
3. Select Impor t and choose your CSV file.
4. Add the device to the Secure Workstations security group.
5. On the Windows 10 device you wish to configure, go to Windows Settings > Update & Security >
Recover y .
a. Choose Get star ted under Reset this PC .
b. Follow the prompts to reset and reconfigure the device with the profile and compliance policies
configured.
After you have configured the device, complete a review and check the configuration. Confirm that the first device
is configured correctly before continuing your deployment.

Assign devices
To assign devices and users, you need to map the selected profiles to your security group. All new users who
require permissions to the service must be added to the security group as well.

Using Sentinel and Windows Defender ATP to monitor and respond to

security incidents
Monitoring the secure workstation deployment can be accomplished by enabling [Sentinel] and utilizing Threat
and Vulnerability Management The guidance will not provide exhaustive threat hunting, but provide good
common sense efforts to monitor and responds to potential security incidents.
We will use Azure Sentinel to:
Collect data from Intune, Azure portal, and Azure AD for user and device monitoring
Help Investigate user and device configuration suspicious activity
And drive the ability to explore security investigations using WDATP
Sentinel monitoring requires that connectors to your data sources such as Azure AD be set up.
1. In the Azure por tal , go to Azure Sentinel (Preview) > Select Add
2. In the Choose a workspace to add to Azure Sentinel Select Create a new workspace
3. Enter:
Log Analytics Workspace - 'Secure Workstation Monitoring'
Subscription - Select your active subscription
Resource Group - select the ** Create New** > Secure Workstation RG > Ok
Location - Select the location that is geographically best suited for your deployment
Price Tier - Select Per GB (2018)
4. Select Ok .
Next we will connect available secure workstation data sources to the monitoring.
1. In the Azure por tal , go to Azure Sentinel workspace > Select Secure Workstation Monitoring
workspace
2. Select Data Connectors
3. Choose Azure Active Director y > Open Connector Page > After reviewing the Prerequisite. Proceed to
Configuration and select Connect for both Azure AD Sign-in Logs, as well as Azure AD Audit Logs.
4. Choose Azure Activity > Open Connector Page > After reviewing the Prerequisite. Proceed to Configure Azure
Activity Logs > Select your subscription > Select Connect
As data is collected by Sentinel you will be able to observe activity by selecting Azure por tal , go to Azure
Sentinel Over view
We will use Windows Defender ATP (WDATP) to:
Continuously observe and monitor vulnerabilities and misconfigurations
Utilize WDATP to prioritize dynamic threats in the wild
Drive correlation of vulnerabilities with endpoint detection and response (EDR) alerts
Use the dashboard to identify machine-level vulnerability during investigations
Push out remediations to Intune
Configure your Defender ATP dashboard. Using guidance at Threat & Vulnerability Management dashboard
overview.

Monitoring Application activity using Microsoft Monitoring Agent

(MMA)
Starting at the Specialized workstation, app locker is enabled for monitoring of application activity on a
workstation. For the monitoring to be integrated in your Log Analytics workspace, an MMA agent and
configuration must be followed.

NOTE
The Specialized workstation profile contains the AppLocker monitoring policies. Deployment of the policies is required for
monitoring of application activity on a client

Deploy the MMA agent with Intune PowerShell script

1. Download the setup script to a local device.
2. Update the parameters, $WorkSpaceID and $WorkSpaceKey
3. Browse to the Azure por tal > Microsoft Intune > Device configuration > PowerShell scripts > Add .
4. Provide a Name for the script and specify the Script location .
5. Select Configure .
a. Set Run this script using the logged on credentials to Yes .
b. Select OK .
6. Select Create .
7. Select Assignments > Select groups .
a. Add the security group Secure Workstations .
b. Select Save .
Next you must set up Log Analytics to receive the new logs
1. In the Azure por tal , go to Log Analytics Workspace > Select - 'Secure Workstation Monitoring'
2. Select Advanced settings > Data > Windows Event Logs
3. In Collect events from the following event logs
4. Enter:
'Microsoft-Windows-AppLocker/EXE and DLL' > Unselect Informational
'Microsoft-Windows-AppLocker/MSI and Script' > Unselect Informational
'Microsoft-Windows-AppLocker/Packaged app-Deployment' > Unselect Informational
 'Microsoft-Windows-AppLocker/Packaged app-Execution' > Unselect Informational
5. Select Save
Application logging will be available in your selected Log Analytics workspace.

Monitoring
Learn how to Detect threats with Azure Sentinel
Investigate incidents with Azure Sentinel
Set up automated threat responses in Azure Sentinel
Understand how to review your Exposure Score
Review Security recommendation
Manage security Remediations
Manage endpoint detection and response
Monitor profiles with Intune profile monitoring.

Next steps
Learn more about Microsoft Intune.
Understand Azure AD.
Work with Microsoft Defender Advanced Threat Protection
Discover Azure Sentinel
 Troubleshooting hybrid Azure Active Directory
joined devices
9/7/2020 • 12 minutes to read • Edit Online

The content of this article is applicable to devices running Windows 10 or Windows Server 2016.
For other Windows clients, see the article Troubleshooting hybrid Azure Active Directory joined down-level
devices.
This article assumes that you have configured hybrid Azure Active Directory joined devices to support the
following scenarios:
Device-based Conditional Access
Enterprise roaming of settings
Windows Hello for Business
This document provides troubleshooting guidance to resolve potential issues.
For Windows 10 and Windows Server 2016, hybrid Azure Active Directory join supports the Windows 10
November 2015 Update and above.

Troubleshoot join failures

Step 1: Retrieve the join status
To retrieve the join status:
1. Open a command prompt as an administrator
2. Type dsregcmd /status
 +----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+

AzureAdJoined: YES
EnterpriseJoined: NO
DeviceId: 5820fbe9-60c8-43b0-bb11-44aee233e4e7
Thumbprint: B753A6679CE720451921302CA873794D94C6204A
KeyContainerId: bae6a60b-1d2f-4d2a-a298-33385f6d05e9
KeyProvider: Microsoft Platform Crypto Provider
TpmProtected: YES
KeySignTest: : MUST Run elevated to test.
Idp: login.windows.net
TenantId: 72b988bf-xxxx-xxxx-xxxx-2d7cd011xxxx
TenantName: Contoso
AuthCodeUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/authorize
AccessTokenUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/token
MdmUrl: https://enrollment.manage-beta.microsoft.com/EnrollmentServer/Discovery.svc
MdmTouUrl: https://portal.manage-beta.microsoft.com/TermsOfUse.aspx
dmComplianceUrl: https://portal.manage-beta.microsoft.com/?portalAction=Compliance
SettingsUrl:
eyJVcmlzIjpbImh0dHBzOi8va2FpbGFuaS5vbmUubWljcm9zb2Z0LmNvbS8iLCJodHRwczovL2thaWxhbmkxLm9uZS5taWNyb3NvZnQuY29tL
yJdfQ==
JoinSrvVersion: 1.0
JoinSrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId: urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion: 1.0
KeySrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId: urn:ms-drs:enterpriseregistration.windows.net
DomainJoined: YES
DomainName: CONTOSO

+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+

NgcSet: YES
NgcKeyId: {C7A9AEDC-780E-4FDA-B200-1AE15561A46B}
WorkplaceJoined: NO
WamDefaultSet: YES
WamDefaultAuthority: organizations
WamDefaultId: https://login.microsoft.com
WamDefaultGUID: {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
AzureAdPrt: YES

Step 2: Evaluate the join status

Review the following fields and make sure that they have the expected values:
DomainJoined : YES
This field indicates whether the device is joined to an on-premises Active Directory or not. If the value is NO , the
device cannot perform a hybrid Azure AD join.
WorkplaceJoined : NO
This field indicates whether the device is registered with Azure AD as a personal device (marked as Workplace
Joined). This value should be NO for a domain-joined computer that is also hybrid Azure AD joined. If the value is
YES , a work or school account was added prior to the completion of the hybrid Azure AD join. In this case, the
account is ignored when using Windows 10 version 1607 or later.
AzureAdJoined : YES
This field indicates whether the device is joined. The value will be YES if the device is either an Azure AD joined
device or a hybrid Azure AD joined device. If the value is NO , the join to Azure AD has not completed yet.
Proceed to next steps for further troubleshooting.
Step 3: Find the phase in which join failed and the errorcode
Windows 10 1803 and above
Look for 'Previous Registration' subsection in the 'Diagnostic Data' section of the join status output. This section is
displayed only if the device is domain joined and is unable to hybrid Azure AD join. The 'Error Phase' field denotes
the phase of the join failure while 'Client ErrorCode' denotes the error code of the Join operation.

+----------------------------------------------------------------------+
Previous Registration : 2019-01-31 09:16:43.000 UTC
Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (e92325d0-xxxx-xxxx-xxxx-94ae875d5245) is not
found.
Https Status : 400
Request Id : 6bff0bd9-820b-484b-ab20-2a4f7b76c58e
+----------------------------------------------------------------------+

Older Windows 10 versions

Use Event Viewer logs to locate the phase and error code for the join failures.
1. Open the User Device Registration event logs in event viewer. Located under Applications and Ser vices
Log > Microsoft > Windows > User Device Registration
2. Look for events with the following eventIDs 304, 305, 307.
Step 4: Check for possible causes and resolutions from the lists below
Pre-check phase
Possible reasons for failure:
Device has no line of sight to the Domain controller.
The device must be on the organization’s internal network or on VPN with network line of sight to an
on-premises Active Directory (AD) domain controller.
Discover phase
Possible reasons for failure:
Service Connection Point (SCP) object misconfigured/unable to read SCP object from DC.
A valid SCP object is required in the AD forest, to which the device belongs, that points to a verified
domain name in Azure AD.
Details can be found in the section Configure a Service Connection Point.
Failure to connect and fetch the discovery metadata from the discovery endpoint.
The device should be able to access https://enterpriseregistration.windows.net , in the SYSTEM
context, to discover the registration and authorization endpoints.
If the on-premises environment requires an outbound proxy, the IT admin must ensure that the
computer account of the device is able to discover and silently authenticate to the outbound proxy.
Failure to connect to user realm endpoint and perform realm discovery. (Windows 10 version 1809 and later
only)
The device should be able to access https://login.microsoftonline.com , in the SYSTEM context, to
perform realm discovery for the verified domain and determine the domain type (managed/federated).
If the on-premises environment requires an outbound proxy, the IT admin must ensure that the SYSTEM
context on the device is able to discover and silently authenticate to the outbound proxy.
Common error codes:
DSREG_AUTOJOIN_ADCONFIG_READ_FAILED (0x801c001d/-2145648611)
Reason: Unable to read the SCP object and get the Azure AD tenant information.
Resolution: Refer to the section Configure a Service Connection Point.
DSREG_AUTOJOIN_DISC_FAILED (0x801c0021/-2145648607)
Reason: Generic Discovery failure. Failed to get the discovery metadata from DRS.
Resolution: Find the suberror below to investigate further.
DSREG_AUTOJOIN_DISC_WAIT_TIMEOUT (0x801c001f/-2145648609)
Reason: Operation timed out while performing Discovery.
Resolution: Ensure that https://enterpriseregistration.windows.net is accessible in the SYSTEM
context. For more information, see the section Network connectivity requirements.
DSREG_AUTOJOIN_USERREALM_DISCOVERY_FAILED (0x801c0021/-2145648611)
Reason: Generic Realm Discovery failure. Failed to determine domain type (managed/federated) from
STS.
Resolution: Find the suberror below to investigate further.
Common suberror codes:
To find the suberror code for the discovery error code, use one of the following methods.
W in dow s 10 18 0 3 an d above

Look for 'DRS Discovery Test' in the 'Diagnostic Data' section of the join status output. This section is displayed
only if the device is domain joined and is unable to hybrid Azure AD join.
 +----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+

Diagnostics Reference : www.microsoft.com/aadjerrors

User Context : UN-ELEVATED User
Client Time : 2019-06-05 08:25:29.000 UTC
AD Connectivity Test : PASS
AD Configuration Test : PASS
DRS Discovery Test : FAIL [0x801c0021/0x80072ee2]
DRS Connectivity Test : SKIPPED
Token acquisition Test : SKIPPED
Fallback to Sync-Join : ENABLED

+----------------------------------------------------------------------+

O l d e r W i n d o w s 1 0 v e r si o n s

Use Event Viewer logs to locate the phase and errorcode for the join failures.
1. Open the User Device Registration event logs in event viewer. Located under Applications and Ser vices
Log > Microsoft > Windows > User Device Registration
2. Look for events with the following eventIDs 201

N e t w o rk e rro rs

WININET_E_CANNOT_CONNECT (0x80072efd/-2147012867)
Reason: Connection with the server could not be established
Resolution: Ensure network connectivity to the required Microsoft resources. For more information, see
Network connectivity requirements.
WININET_E_TIMEOUT (0x80072ee2/-2147012894)
Reason: General network timeout.
Resolution: Ensure network connectivity to the required Microsoft resources. For more information, see
Network connectivity requirements.
WININET_E_DECODING_FAILED (0x80072f8f/-2147012721)
Reason: Network stack was unable to decode the response from the server.
Resolution: Ensure that network proxy is not interfering and modifying the server response.
HTTP e rro rs
 DSREG_DISCOVERY_TENANT_NOT_FOUND (0x801c003a/-2145648582)
Reason: SCP object configured with wrong tenant ID. Or no active subscriptions were found in the
tenant.
Resolution: Ensure SCP object is configured with the correct Azure AD tenant ID and active
subscriptions or present in the tenant.
DSREG_SERVER_BUSY (0x801c0025/-2145648603)
Reason: HTTP 503 from DRS server.
Resolution: Server is currently unavailable. future join attempts will likely succeed once server is back
online.
O t h e r e rro rs

E_INVALIDDATA (0x8007000d/-2147024883)
Reason: Server response JSON couldn't be parsed. Likely due to proxy returning HTTP 200 with an
HTML auth page.
Resolution: If the on-premises environment requires an outbound proxy, the IT admin must ensure that
the SYSTEM context on the device is able to discover and silently authenticate to the outbound proxy.
Authentication phase
Applicable only for federated domain accounts.
Reasons for failure:
Unable to get an Access token silently for DRS resource.
Windows 10 devices acquire auth token from the federation service using Integrated Windows
Authentication to an active WS-Trust endpoint. Details: Federation Service Configuration
Common error codes:
Use Event Viewer logs to locate the error code, suberror code, server error code, and server error message.
1. Open the User Device Registration event logs in event viewer. Located under Applications and Ser vices
Log > Microsoft > Windows > User Device Registration
2. Look for events with the following eventID 305

C o n fi g u r a t i o n e r r o r s

ERROR_ADAL_PROTOCOL_NOT_SUPPORTED (0xcaa90017/-894894057)
Reason: Authentication protocol is not WS-Trust.
Resolution: The on-premises identity provider must support WS-Trust
ERROR_ADAL_FAILED_TO_PARSE_XML (0xcaa9002c/-894894036)
Reason: On-premises federation service did not return an XML response.
 Resolution: Ensure MEX endpoint is returning a valid XML. Ensure proxy is not interfering and returning
non-xml responses.
ERROR_ADAL_COULDNOT_DISCOVER_USERNAME_PASSWORD_ENDPOINT (0xcaa90023/-
894894045)
Reason: Could not discover endpoint for username/password authentication.
Resolution: Check the on-premises identity provider settings. Ensure that the WS-Trust endpoints are
enabled and ensure the MEX response contains these correct endpoints.
N et w o r k er r o r s

ERROR_ADAL_INTERNET_TIMEOUT (0xcaa82ee2/-894947614)
Reason: General network timeout.
Resolution: Ensure that https://login.microsoftonline.com is accessible in the SYSTEM context. Ensure
the on-premises identity provider is accessible in the SYSTEM context. For more information, see
Network connectivity requirements.
ERROR_ADAL_INTERNET_CONNECTION_ABORTED (0xcaa82efe/-894947586)
Reason: Connection with the auth endpoint was aborted.
Resolution: Retry after sometime or try joining from an alternate stable network location.
ERROR_ADAL_INTERNET_SECURE_FAILURE (0xcaa82f8f/-894947441)
Reason: The Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), certificate
sent by the server could not be validated.
Resolution: Check the client time skew. Retry after sometime or try joining from an alternate stable
network location.
ERROR_ADAL_INTERNET_CANNOT_CONNECT (0xcaa82efd/-894947587)
Reason: The attempt to connect to https://login.microsoftonline.com failed.
Resolution: Check network connection to https://login.microsoftonline.com .
O t h er er r o r s

ERROR_ADAL_SERVER_ERROR_INVALID_GRANT (0xcaa20003/-895352829)
Reason: SAML token from the on-premises identity provider was not accepted by Azure AD.
Resolution: Check the federation server settings. Look for the server error code in the authentication
logs.
ERROR_ADAL_WSTRUST_REQUEST_SECURITYTOKEN_FAILED (0xcaa90014/-894894060)
Reason: Server WS-Trust response reported fault exception and it failed to get assertion
Resolution: Check the federation server settings. Look for the server error code in the authentication
logs.
ERROR_ADAL_WSTRUST_TOKEN_REQUEST_FAIL (0xcaa90006/-894894074)
Reason: Received an error when trying to get access token from the token endpoint.
Resolution: Look for the underlying error in the ADAL log.
ERROR_ADAL_OPERATION_PENDING (0xcaa1002d/-895418323)
Reason: General ADAL failure
Resolution: Look for the suberror code or server error code from the authentication logs.
Join Phase
Reasons for failure:
Find the registration type and look for the error code from the list below.
Windows 10 1803 and above
Look for 'Previous Registration' subsection in the 'Diagnostic Data' section of the join status output. This section is
displayed only if the device is domain joined and is unable to hybrid Azure AD join. 'Registration Type' field
denotes the type of join performed.
 +----------------------------------------------------------------------+
Previous Registration : 2019-01-31 09:16:43.000 UTC
Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (e92325d0-7ac4-4714-88a1-94ae875d5245) is not
found.
Https Status : 400
Request Id : 6bff0bd9-820b-484b-ab20-2a4f7b76c58e
+----------------------------------------------------------------------+

Older Windows 10 versions

Use Event Viewer logs to locate the phase and errorcode for the join failures.
1. Open the User Device Registration event logs in event viewer. Located under Applications and Ser vices
Log > Microsoft > Windows > User Device Registration
2. Look for events with the following eventIDs 204

H T T P e r r o r s r e t u r n e d fr o m D R S se r v e r

DSREG_E_DIRECTORY_FAILURE (0x801c03f2/-2145647630)
Reason: Received an error response from DRS with ErrorCode: "DirectoryError"
Resolution: Refer to the server error code for possible reasons and resolutions.
DSREG_E_DEVICE_AUTHENTICATION_ERROR (0x801c0002/-2145648638)
Reason: Received an error response from DRS with ErrorCode: "AuthenticationError" and ErrorSubCode
is NOT "DeviceNotFound".
Resolution: Refer to the server error code for possible reasons and resolutions.
DSREG_E_DEVICE_INTERNALSERVICE_ERROR (0x801c0006/-2145648634)
Reason: Received an error response from DRS with ErrorCode: "DirectoryError"
Resolution: Refer to the server error code for possible reasons and resolutions.
T P M er r o r s

NTE_BAD_KEYSET (0x80090016/-2146893802)
Reason: TPM operation failed or was invalid
 Resolution: Likely due to a bad sysprep image. Ensure the machine from which the sysprep image was
created is not Azure AD joined, hybrid Azure AD joined, or Azure AD registered.
TPM_E_PCP_INTERNAL_ERROR (0x80290407/-2144795641)
Reason: Generic TPM error.
Resolution: Disable TPM on devices with this error. Windows 10 version 1809 and higher automatically
detects TPM failures and completes hybrid Azure AD join without using the TPM.
TPM_E_NOTFIPS (0x80280036/-2144862154)
Reason: TPM in FIPS mode not currently supported.
Resolution: Disable TPM on devices with this error. Windows 1809 automatically detects TPM failures
and completes hybrid Azure AD join without using the TPM.
NTE_AUTHENTICATION_IGNORED (0x80090031/-2146893775)
Reason: TPM locked out.
Resolution: Transient error. Wait for the cooldown period. Join attempt after some time should succeed.
More Information can be found in the article TPM fundamentals
N e t w o r k Er r o r s

WININET_E_TIMEOUT (0x80072ee2/-2147012894)
Reason: General network time out trying to register the device at DRS
Resolution: Check network connectivity to https://enterpriseregistration.windows.net .
WININET_E_NAME_NOT_RESOLVED (0x80072ee7/-2147012889)
Reason: The server name or address could not be resolved.
Resolution: Check network connectivity to https://enterpriseregistration.windows.net . Ensure DNS
resolution for the hostname is accurate in the n/w and on the device.
WININET_E_CONNECTION_ABORTED (0x80072efe/-2147012866)
Reason: The connection with the server was terminated abnormally.
Resolution: Retry after sometime or try joining from an alternate stable network location.
F e d e r a t e d j o i n se r v e r Er r o r s

SERVER ERRO R C O DE SERVER ERRO R M ESSA GE P O SSIB L E REA SO N S RESO L UT IO N

DirectoryError Your request is throttled Expected error. Possibly due Retry join after the
temporarily. Please try after to making multiple cooldown period
300 seconds. registration requests in
quick succession.

Sy n c j o i n se r v e r Er r o r s

SERVER ERRO R C O DE SERVER ERRO R M ESSA GE P O SSIB L E REA SO N S RESO L UT IO N

DirectoryError AADSTS90002: Tenant not Tenant ID in SCP object is Ensure SCP object is
found. This error may incorrect configured with the correct
happen if there are no Azure AD tenant ID and
active subscriptions for the active subscriptions and
tenant. Check with your present in the tenant.
subscription administrator.

DirectoryError The device object by the Expected error for sync join. Wait for the Azure AD
given ID is not found. The device object has not Connect sync to complete
synced from AD to Azure and the next join attempt
AD after sync completion will
resolve the issue
 SERVER ERRO R C O DE SERVER ERRO R M ESSA GE P O SSIB L E REA SO N S RESO L UT IO N

AuthenticationError The verification of the target The certificate on the Azure Wait for the Azure AD
computer's SID AD device doesn't match the Connect sync to complete
certificate used to sign the and the next join attempt
blob during the sync join. after sync completion will
This error typically means resolve the issue
sync hasn’t completed yet.

Step 5: Collect logs and contact Microsoft Support

Download the file Auth.zip from https://github.com/CSS-Windows/WindowsDiag/tree/master/ADS/AUTH
1. Unzip the files and rename the included files star t-auth.txt and stop-auth.txt to star t-auth.cmd and stop-
auth.cmd .
2. From an elevated command prompt, run star t-auth.cmd .
3. Use Switch Account to toggle to another session with the problem user.
4. Reproduce the issue.
5. Use Switch Account to toggle back to the admin session running the tracing.
6. From an elevated command prompt, run stop-auth.cmd .
7. Zip and send the folder Authlogs from the folder where the scripts were executed from.

Troubleshoot Post-Join issues

Retrieve the join status
WamDefaultSet: YES and AzureADPrt: YES
These fields indicate whether the user has successfully authenticated to Azure AD when signing in to the device. If
the values are NO , it could be due:
Bad storage key in the TPM associated with the device upon registration (check the KeySignTest while running
elevated).
Alternate Login ID
HTTP Proxy not found

Known issues
Under Settings -> Accounts -> Access Work or School, Hybrid Azure AD joined devices may show two
different accounts, one for Azure AD and one for on-premises AD, when connected to mobile hotspots or
external WiFi networks. This is only a UI issue and does not have any impact on functionality.

Next steps
Continue troubleshooting devices using the dsregcmd command
For questions, see the device management FAQ
 Troubleshooting devices using the dsregcmd
command
3/23/2020 • 9 minutes to read • Edit Online

The dsregcmd /status utility must be run as a domain user account.

Device state
This section lists the device join state parameters. The table below lists the criteria for the device to be in various
join states.

A Z UREA DJO IN ED EN T ERP RISE JO IN ED DO M A IN JO IN ED DEVIC E STAT E

YES NO NO Azure AD Joined

NO NO YES Domain Joined

YES NO YES Hybrid AD Joined

NO YES YES On-premises DRS Joined

NOTE
Workplace Join (Azure AD registered) state is displayed in the "User State" section

AzureAdJoined: - Set to “YES” if the device is Joined to Azure AD. “NO” otherwise.
EnterpriseJoined: - Set to “YES” if the device is Joined to an on-premises DRS. A device cannot be both
EnterpriseJoined and AzureAdJoined.
DomainJoined: - Set to “YES” if the device is joined to a domain (AD).
DomainName: - Set to the name of the domain if the device is joined to a domain.
Sample device state output

+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
DomainName : HYBRIDADFS
+----------------------------------------------------------------------+

Device details
Displayed only when the device is Azure AD joined or hybrid Azure AD joined (not Azure AD registered). This
section lists device identifying details stored in the cloud.
DeviceId: - Unique ID of the device in the Azure AD tenant
Thumbprint: - Thumbprint of the device certificate
 DeviceCer tificateValidity: - Validity of the device certificate
KeyContainerId: - ContainerId of the device private key associated with the device certificate
KeyProvider : - KeyProvider (Hardware/Software) used to store the device private key.
TpmProtected: - “YES” if the device private key is stored in a Hardware TPM.
Sample device details output

+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+

DeviceId : e92325d0-xxxx-xxxx-xxxx-94ae875dxxxx
Thumbprint : D293213EF327483560EED8410CAE36BB67208179
DeviceCertificateValidity : [ 2019-01-11 21:02:50.000 UTC -- 2029-01-11 21:32:50.000 UTC ]
KeyContainerId : 13e68a58-xxxx-xxxx-xxxx-a20a2411xxxx
KeyProvider : Microsoft Software Key Storage Provider
TpmProtected : NO
+----------------------------------------------------------------------+

Tenant details
Displayed only when the device is Azure AD joined or hybrid Azure AD joined (not Azure AD registered). This
section lists the common tenant details when a device is joined to Azure AD.

NOTE
If the MDM URLs in this section are empty, it indicates that the MDM was either not configured or current user is not in
scope of MDM enrollment. Check the Mobility settings in Azure AD to review your MDM configuration.

NOTE
Even if you see MDM URLs this does not mean that the device is managed by an MDM. The information is displayed if the
tenant has MDM configuration for auto-enrollment even if the device itself is not managed.

Sample tenant details output

 +----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+

TenantName : HybridADFS
TenantId : 96fa76d0-xxxx-xxxx-xxxx-eb60cc22xxxx
Idp : login.windows.net
AuthCodeUrl : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-
eb60cc22xxxx/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-
eb60cc22xxxx/oauth2/token
MdmUrl : https://enrollment.manage-beta.microsoft.com/EnrollmentServer/Discovery.svc
MdmTouUrl : https://portal.manage-beta.microsoft.com/TermsOfUse.aspx
MdmComplianceUrl : https://portal.manage-beta.microsoft.com/?portalAction=Compliance
SettingsUrl :
eyJVxxxxIjpbImh0dHBzOi8va2FpbGFuaS5vbmUubWljcm9zb2Z0LmNvbS8iLCJodHRwczovL2thaWxhbmkxLm9uZS5taWNyb3NvZnQuY29tL
yxxxx==
JoinSrvVersion : 1.0
JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion : 1.0
KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId : urn:ms-drs:enterpriseregistration.windows.net
WebAuthNSrvVersion : 1.0
WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/96fa76d0-xxxx-xxxx-xxxx-
eb60cc22xxxx/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvVer : 1.0
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/96fa76d0-xxxx-xxxx-xxxx-
eb60cc22xxxx/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
+----------------------------------------------------------------------+

User state
This section lists the status of various attributes for the user currently logged into the device.

NOTE
The command must run in a user context to retrieve valid status.

NgcSet: - Set to “YES” if a Windows Hello key is set for the current logged on user.
NgcKeyId: - ID of the Windows Hello key if one is set for the current logged on user.
CanReset: - Denotes if the Windows Hello key can be reset by the user.
Possible values: - DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, or Unknown if error.
WorkplaceJoined: - Set to “YES” if Azure AD registered accounts have been added to the device in the
current NTUSER context.
WamDefaultSet: - Set to “YES” if a WAM default WebAccount is created for the logged in user. This field could
display an error if dsreg /status is run from an elevated command prompt.
WamDefaultAuthority: - Set to “organizations” for Azure AD.
WamDefaultId: - Always “https://login.microsoft.com” for Azure AD.
WamDefaultGUID: - The WAM provider’s (Azure AD/Microsoft account) GUID for the default WAM
WebAccount.
Sample user state output
 +----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+

NgcSet : YES
NgcKeyId : {FA0DB076-A5D7-4844-82D8-50A2FB42EC7B}
CanReset : DestructiveAndNonDestructive
WorkplaceJoined : NO
WamDefaultSet : YES
WamDefaultAuthority : organizations
WamDefaultId : https://login.microsoft.com
WamDefaultGUID : { B16898C6-A148-4967-9171-64D755DA8520 } (AzureAd)

+----------------------------------------------------------------------+

SSO state
This section can be ignored for Azure AD registered devices.

NOTE
The command must run in a user context to retrieve valid status for that user.

AzureAdPr t: - Set to “YES” if a PRT is present on the device for the logged-on user.
AzureAdPr tUpdateTime: - Set to the time in UTC when the PRT was last updated.
AzureAdPr tExpir yTime: - Set to the time in UTC when the PRT is going to expire if it is not renewed.
AzureAdPr tAuthority: - Azure AD authority URL
EnterprisePr t: - Set to “YES” if the device has PRT from on-premises ADFS. For hybrid Azure AD joined
devices the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises
joined devices will only have an Enterprise PRT.
EnterprisePr tUpdateTime: - Set to the time in UTC when the Enterprise PRT was last updated.
EnterprisePr tExpir yTime: - Set to the time in UTC when the PRT is going to expire if it is not renewed.
EnterprisePr tAuthority: - ADFS authority URL
Sample SSO state output

+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+

AzureAdPrt : YES
AzureAdPrtUpdateTime : 2019-01-24 19:15:26.000 UTC
AzureAdPrtExpiryTime : 2019-02-07 19:15:26.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-eb60cc22xxxx
EnterprisePrt : YES
EnterprisePrtUpdateTime : 2019-01-24 19:15:33.000 UTC
EnterprisePrtExpiryTime : 2019-02-07 19:15:33.000 UTC
EnterprisePrtAuthority : https://fs.hybridadfs.nttest.microsoft.com:443/adfs

+----------------------------------------------------------------------+

Diagnostic data
Pre -join diagnostics
This section is displayed only if the device is domain joined and is unable to hybrid Azure AD join.
This section performs various tests to help diagnose join failures. This section also includes the details of the
previous (?). This information includes the error phase, the error code, the server request ID, server response http
status, server response error message.
User Context: - The context in which the diagnostics are run. Possible values: SYSTEM, UN-ELEVATED User,
ELEVATED User.

NOTE
Since the actual join is performed in SYSTEM context, running the diagnostics in SYSTEM context is closest to the
actual join scenario. To run diagnostics in SYSTEM context, the dsregcmd /status command must be run from an
elevated command prompt.

Client Time: - The system time in UTC.

AD Connectivity Test: - Test performs a connectivity test to the domain controller. Error in this test will
likely result in Join errors in pre-check phase.
AD Configuration Test: - Test reads and verifies whether the SCP object is configured properly in the on-
premises AD forest. Errors in this test would likely result in Join errors in the discover phase with the error
code 0x801c001d.
DRS Discover y Test: - Test gets the DRS endpoints from discovery metadata endpoint and performs a
user realm request. Errors in this test would likely result in Join errors in the discover phase.
DRS Connectivity Test: - Test performs basic connectivity test to the DRS endpoint.
Token acquisition Test: - Test tries to get an Azure AD authentication token if the user tenant is federated.
Errors in this test would likely result in Join errors in the auth phase. If auth fails sync join will be attempted
as fallback, unless fallback is explicitly disabled with the below registry key settings.

Keyname: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ
Value: FallbackToSyncJoin
Type: REG_DWORD
Value: 0x0 -> Disabled
Value: 0x1 -> Enabled
Default (No Key): Enabled

Fallback to Sync-Join: - Set to “Enabled” if the above registry key, to prevent the fallback to sync join with
auth failures, is NOT present. This option is available from Windows 10 1803 and later.
Previous Registration: - Time the previous Join attempt occurred. Only failed Join attempts are logged.
Error Phase: - The stage of the join in which it was aborted. Possible values are pre-check, discover, auth, join.
Client ErrorCode: - Client error code returned (HRESULT).
Ser ver ErrorCode: - Server error code if a request was sent to the server and server responded back with an
error code.
Ser ver Message: - Server message returned along with the error code.
Https Status: - Http status returned by the server.
Request ID: - The client requestId sent to the server. Useful to correlate with server-side logs.
Sample pre -join diagnostics output
The following example shows diagnostics test failing with a discovery error.
 +----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+

Diagnostics Reference : www.microsoft.com/aadjerrors

User Context : SYSTEM
Client Time : 2019-01-31 09:25:31.000 UTC
AD Connectivity Test : PASS
AD Configuration Test : PASS
DRS Discovery Test : FAIL [0x801c0021/0x801c000c]
DRS Connectivity Test : SKIPPED
Token acquisition Test : SKIPPED
Fallback to Sync-Join : ENABLED

Previous Registration : 2019-01-31 09:23:30.000 UTC

Error Phase : discover
Client ErrorCode : 0x801c0021

+----------------------------------------------------------------------+

The following example shows diagnostics tests are passing but the registration attempt failed with a directory
error, which is expected for sync join. Once the Azure AD Connect synchronization job completes, the device will
be able to join.

+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+

Diagnostics Reference : www.microsoft.com/aadjerrors

User Context : SYSTEM
Client Time : 2019-01-31 09:16:50.000 UTC
AD Connectivity Test : PASS
AD Configuration Test : PASS
DRS Discovery Test : PASS
DRS Connectivity Test : PASS
Token acquisition Test : PASS
Fallback to Sync-Join : ENABLED

Previous Registration : 2019-01-31 09:16:43.000 UTC

Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (e92325d0-7ac4-4714-88a1-94ae875d5245) is not
found.
Https Status : 400
Request Id : 6bff0bd9-820b-484b-ab20-2a4f7b76c58e

+----------------------------------------------------------------------+

Post-join diagnostics
This section displays the output of sanity checks performed on a device joined to the cloud.
AadRecover yEnabled: - If “YES”, the keys stored in the device are not usable and the device is marked for
recovery. The next sign in will trigger the recovery flow and re-register the device.
KeySignTest: - If “PASSED” the device keys are in good health. If KeySignTest fails, the device will usually be
marked for recovery. The next sign in will trigger the recovery flow and re-register the device. For hybrid Azure
AD joined devices the recovery is silent. While Azure AD joined or Azure AD registered, devices will prompt for
user authentication to recover and re-register the device if necessary. The KeySignTest requires elevated
privileges.
Sample post-join diagnostics output

+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+

AadRecoveryEnabled: NO
KeySignTest : PASSED
+----------------------------------------------------------------------+

NGC prerequisite check

This section performs the perquisite checks for the provisioning of Windows Hello for Business (WHFB).

NOTE
You may not see NGC pre-requisite check details in dsregcmd /status if the user already successfully configured WHFB.

IsDeviceJoined: - Set to “YES” if the device is joined to Azure AD.

IsUserAzureAD: - Set to “YES” if the logged in user is present in Azure AD .
PolicyEnabled: - Set to "YES" if the WHFB policy is enabled on the device.
PostLogonEnabled: - Set to "YES" if WHFB enrollment is triggered natively by the platform. If it's set to "NO",
it indicates that Windows Hello for Business enrollment is triggered by a custom mechanism
DeviceEligible: - Set to “YES” if the device meets the hardware requirement for enrolling with WHFB.
SessionIsNotRemote: - Set to “YES” if the current user is logged in directly to the device and not remotely.
Cer tEnrollment: - Specific to WHFB Certificate Trust deployment, indicating the certificate enrollment
authority for WHFB. Set to “enrollment authority” if source of WHFB policy is Group Policy, “mobile device
management” if source is MDM. “none” otherwise
AdfsRefreshToken: - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is
“enrollment authority”. Indicates if the device has an enterprise PRT for the user.
AdfsRaIsReady: - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is
“enrollment authority”. Set to “YES” if ADFS indicated in discovery metadata that it supports WHFB and if
logon certificate template is available.
LogonCer tTemplateReady: - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment
is “enrollment authority”. Set to “YES” if state of logon certificate template is valid and helps troubleshoot ADFS
RA.
PreReqResult: - Provides result of all WHFB prerequisite evaluation. Set to “Will Provision” if WHFB
enrollment would be launched as a post-logon task when user signs in next time.
Sample NGC prerequisite check output
 +----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+

IsDeviceJoined : YES
IsUserAzureAD : YES
PolicyEnabled : YES
PostLogonEnabled : YES
DeviceEligible : YES
SessionIsNotRemote : YES
CertEnrollment : enrollment authority
AdfsRefreshToken : YES
AdfsRaIsReady : YES
LogonCertTemplateReady : YES ( StateReady )
PreReqResult : WillProvision
+----------------------------------------------------------------------+

Next steps
For questions, see the device management FAQ
 Troubleshooting hybrid Azure Active Directory
joined down-level devices
11/22/2019 • 4 minutes to read • Edit Online

This article is applicable only to the following devices:

Windows 7
Windows 8.1
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
For Windows 10 or Windows Server 2016, see Troubleshooting hybrid Azure Active Directory joined Windows 10
and Windows Server 2016 devices.
This article assumes that you have configured hybrid Azure Active Directory joined devices to support the
following scenarios:
Device-based Conditional Access
This article provides you with troubleshooting guidance on how to resolve potential issues.
What you should know:
Hybrid Azure AD join for downlevel Windows devices works slightly differently than it does in Windows 10.
Many customers do not realize that they need AD FS (for federated domains) or Seamless SSO configured (for
managed domains).
For customers with federated domains, if the Service Connection Point (SCP) was configured such that it
points to the managed domain name (for example, contoso.onmicrosoft.com, instead of contoso.com), then
Hybrid Azure AD Join for downlevel Windows devices will not work.
The maximum number of devices per user currently also applies to downlevel hybrid Azure AD joined devices.
The same physical device appears multiple times in Azure AD when multiple domain users sign-in the
downlevel hybrid Azure AD joined devices. For example, if jdoe and jharnett sign-in to a device, a separate
registration (DeviceID) is created for each of them in the USER info tab.
You can also get multiple entries for a device on the user info tab because of a reinstallation of the operating
system or a manual re-registration.
The initial registration / join of devices is configured to perform an attempt at either sign-in or lock / unlock.
There could be 5-minute delay triggered by a task scheduler task.
Make sure KB4284842 is installed, in case of Windows 7 SP1 or Windows Server 2008 R2 SP1. This update
prevents future authentication failures due to customer's access loss to protected keys after changing
password.

Step 1: Retrieve the registration status

To verify the registration status:
1. Sign on with the user account that has performed a hybrid Azure AD join.
2. Open the command prompt
3. Type "%programFiles%\Microsoft Workplace Join\autoworkplace.exe" /i
This command displays a dialog box that provides you with details about the join status.

Step 2: Evaluate the hybrid Azure AD join status

If the device was not hybrid Azure AD joined, you can attempt to do hybrid Azure AD join by clicking on the "Join"
button. If the attempt to do hybrid Azure AD join fails, the details about the failure will be shown.
The most common issues are:
A misconfigured AD FS or Azure AD or Network issues

Autoworkplace.exe is unable to silently authenticate with Azure AD or AD FS. This could be caused by
missing or misconfigured AD FS (for federated domains) or missing or misconfigured Azure AD
Seamless Single Sign-On (for managed domains) or network issues.
It could be that multi-factor authentication (MFA) is enabled/configured for the user and
WIAORMULTIAUTHN is not configured at the AD FS server.
Another possibility is that home realm discovery (HRD) page is waiting for user interaction, which
prevents autoworkplace.exe from silently requesting a token.
It could be that AD FS and Azure AD URLs are missing in IE's intranet zone on the client.
Network connectivity issues may be preventing autoworkplace.exe from reaching AD FS or the Azure
AD URLs.
Autoworkplace.exe requires the client to have direct line of sight from the client to the organization's
on-premises AD domain controller, which means that hybrid Azure AD join succeeds only when the
client is connected to organization's intranet.
Your organization uses Azure AD Seamless Single Sign-On, https://autologon.microsoftazuread-sso.com
or https://aadg.windows.net.nsatc.net are not present on the device's IE intranet settings, and Allow
updates to status bar via script is not enabled for the Intranet zone.
You are not signed on as a domain user
 There are a few different reasons why this can occur:
The signed in user is not a domain user (for example, a local user). Hybrid Azure AD join on down-level
devices is supported only for domain users.
The client is not able to connect to a domain controller.
A quota has been reached

The service is not responding

You can also find the status information in the event log under: Applications and Ser vices Log\Microsoft-
Workplace Join
The most common causes for a failed hybrid Azure AD join are:
Your computer is not connected to your organization’s internal network or to a VPN with a connection to your
on-premises AD domain controller.
You are logged on to your computer with a local computer account.
Service configuration issues:
The AD FS server has not been configured to support WIAORMULTIAUTHN .
Your computer's forest has no Service Connection Point object that points to your verified domain name
in Azure AD
Or if your domain is managed, then Seamless SSO was not configured or working.
A user has reached the limit of devices.

Next steps
For questions, see the device management FAQ
 Troubleshooting Enterprise State Roaming settings in
Azure Active Directory
9/7/2020 • 9 minutes to read • Edit Online

This topic provides information on how to troubleshoot and diagnose issues with Enterprise State Roaming, and
provides a list of known issues.

NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will
continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure
PowerShell.

NOTE
This article applies to the Microsoft Edge Legacy HTML-based browser launched with Windows 10 in July 2015. The article
does not apply to the new Microsoft Edge Chromium-based browser released on January 15, 2020. For more information
on the Sync behavior for the new Microsoft Edge, see the article Microsoft Edge Sync.

Preliminary steps for troubleshooting

Before you start troubleshooting, verify that the user and device have been configured properly, and that all the
requirements of Enterprise State Roaming are met by the device and the user.
1. Windows 10, with the latest updates, and a minimum Version 1511 (OS Build 10586 or later) is installed on the
device.
2. The device is Azure AD joined or hybrid Azure AD joined. For more information, see how to get a device under
the control of Azure AD.
3. Ensure that Enterprise State Roaming is enabled for the tenant in Azure AD as described in To enable
Enterprise State Roaming. You can enable roaming for all users or for only a selected group of users.
4. The user is assigned an Azure Active Directory Premium license.
5. The device must be restarted and the user must sign in again to access Enterprise State Roaming features.

Information to include when you need help

If you cannot solve your issue with the guidance below, you can contact our support engineers. When you contact
them, include the following information:
General description of the error : Are there error messages seen by the user? If there was no error message,
describe the unexpected behavior you noticed, in detail. What features are enabled for sync and what is the
user expecting to sync? Are multiple features not syncing or is it isolated to one?
Users affected – Is sync working/failing for one user or multiple users? How many devices are involved per
user? Are all of them not syncing or are some of them syncing and some not syncing?
Information about the user – What identity is the user using to sign in to the device? How is the user
signing in to the device? Are they part of a selected security group allowed to sync?
Information about the device – Is this device Azure AD-joined or domain-joined? What build is the device
 on? What are the most recent updates?
Date / Time / Timezone – What was the precise date and time you saw the error (include the timezone)?
Including this information helps us solve your problem as quickly as possible.

Troubleshooting and diagnosing issues

This section gives suggestions on how to troubleshoot and diagnose problems related to Enterprise State
Roaming.

Verify sync, and the “Sync your settings” settings page

1. After joining your Windows 10 PC to a domain that is configured to allow Enterprise State Roaming, sign on
with your work account. Go to Settings > Accounts > Sync Your Settings and confirm that sync and the
individual settings are on, and that the top of the settings page indicates that you are syncing with your
work account. Confirm the same account is also used as your login account in Settings > Accounts >
Your Info .
2. Verify that sync works across multiple machines by making some changes on the original machine, such as
moving the taskbar to the right or top side of the screen. Watch the change propagate to the second
machine within five minutes.
Locking and unlocking the screen (Win + L) can help trigger a sync.
You must be signing in with the same account on both PCs for sync to work – as Enterprise State
Roaming is tied to the user account and not the machine account.
Potential issue : If the controls in the Settings page are not available, and you see the message “Some Windows
features are only available if you are using a Microsoft account or work account.” This issue might arise for devices
that are set up to be domain-joined and registered to Azure AD, but the device has not yet successfully
authenticated to Azure AD. A possible cause is that the device policy must be applied, but this application happens
asynchronously, and could be delayed by a few hours.
Verify the device registration status
Enterprise State Roaming requires the device to be registered with Azure AD. Although not specific to Enterprise
State Roaming, following the instructions below can help confirm that the Windows 10 Client is registered, and
confirm thumbprint, Azure AD settings URL, NGC status, and other information.
1. Open the command prompt unelevated. To do this in Windows, open the Run launcher (Win + R) and type
“cmd” to open.
2. Once the command prompt is open, type “dsregcmd.exe /status”.
3. For expected output, the AzureAdJoined field value should be “YES”, WamDefaultSet field value should be
“YES”, and the WamDefaultGUID field value should be a GUID with “(AzureAd)” at the end.
Potential issue : WamDefaultSet and AzureAdJoined both have “NO” in the field value, the device was
domain-joined and registered with Azure AD, and the device does not sync. If it is showing this, the device may
need to wait for policy to be applied or the authentication for the device failed when connecting to Azure AD. The
user may have to wait a few hours for the policy to be applied. Other troubleshooting steps may include retrying
autoregistration by signing out and back in, or launching the task in Task Scheduler. In some cases, running
“dsregcmd.exe /leave” in an elevated command prompt window, rebooting, and trying registration again may help
with this issue.
Potential issue : The field for SettingsUrl is empty and the device does not sync. The user may have last logged
in to the device before Enterprise State Roaming was enabled in the Azure Active Directory Portal. Restart the
device and have the user login. Optionally, in the portal, try having the IT Admin navigate to Azure Active
Director y > Devices > Enterprise State Roaming disable and re-enable Users may sync settings and app
data across devices . Once re-enabled, restart the device and have the user login. If this does not resolve the
issue, SettingsUrl may be empty if there is a bad device certificate. In this case, running “dsregcmd.exe /leave” in
an elevated command prompt window, rebooting, and trying registration again may help with this issue.

Enterprise State Roaming and Multi-Factor Authentication

Under certain conditions, Enterprise State Roaming can fail to sync data if Azure Multi-Factor Authentication is
configured. For more information on these symptoms, see the support document KB3193683.
Potential issue : If your device is configured to require Multi-Factor Authentication on the Azure Active Directory
portal, you may fail to sync settings while signing in to a Windows 10 device using a password. This type of Multi-
Factor Authentication configuration is intended to protect an Azure administrator account. Admin users may still
be able to sync by signing in to their Windows 10 devices with their Microsoft Passport for Work PIN or by
completing Multi-Factor Authentication while accessing other Azure services like Office 365.
Potential issue : Sync can fail if the admin configures the Active Directory Federation Services Multi-Factor
Authentication Conditional Access policy and the access token on the device expires. Ensure that you sign in and
sign out using the Microsoft Passport for Work PIN or complete Multi-Factor Authentication while accessing other
Azure services like Office 365.
Event Viewer
For advanced troubleshooting, Event Viewer can be used to find specific errors. These are documented in the table
below. The events can be found under Event Viewer > Applications and Ser vices Logs > Microsoft >
Windows > SettingSync-Azure and for identity-related issues with sync Applications and Ser vices Logs >
Microsoft > Windows > AAD .

Known issues
Sync does not work on devices that have apps side -loaded using MDM software
Affects devices running the Windows 10 Anniversary Update (Version 1607). In Event Viewer under the
SettingSync-Azure logs, the Event ID 6013 with error 80070259 is frequently seen.
Recommended action
Make sure the Windows 10 v1607 client has the August 23, 2016 Cumulative Update (KB3176934 OS Build
14393.82).

Internet Explorer Favorites do not sync

Affects devices running the Windows 10 November Update (Version 1511).
Recommended action
Make sure the Windows 10 v1511 client has the July 2016 Cumulative Update (KB3172985 OS Build 10586.494).

Theme is not syncing, as well as data protected with Windows Information Protection
To prevent data leakage, data that is protected with Windows Information Protection will not sync through
Enterprise State Roaming for devices using the Windows 10 Anniversary Update.
Recommended action
None. Future updates to Windows may resolve this issue.

Date, Time, and Region settings do not sync on domain-joined device

Devices that are domain-joined will not experience sync for the setting Date, Time, and Region: automatic time.
Using automatic time may override the other Date, Time, and Region settings and cause those settings not to sync.
Recommended action
None.

UAC Prompts when syncing passwords

Affects devices running the Windows 10 November Update (Version 1511) with a wireless NIC that is configured
to sync passwords.
Recommended action
Make sure the Windows 10 v1511 client has the Cumulative Update (KB3140743 OS Build 10586.494).

Sync does not work on devices that use smart card for login
If you attempt to sign in to your Windows device using a smart card or virtual smart card, settings sync will stop
working.
Recommended action
None. Future updates to Windows may resolve this issue.

Domain-joined device is not syncing after leaving corporate network

Domain-joined devices registered to Azure AD may experience sync failure if the device is off-site for extended
periods of time, and domain authentication can't complete.
Recommended action
Connect the device to a corporate network so that sync can resume.

Azure AD Joined device is not syncing and the user has a mixed case User Principal Name.
If the user has a mixed case UPN (for example, UserName instead of username) and the user is on an Azure AD
Joined device, which has upgraded from Windows 10 Build 10586 to 14393, the user's device may fail to sync.
Recommended action
The user will need to unjoin and rejoin the device to the cloud. To do this, login as the Local Administrator user and
unjoin the device by going to Settings > System > About and select "Manage or disconnect from work or
school". Clean up the files below, and then Azure AD Join the device again in Settings > System > About and
selecting "Connect to Work or School". Continue to join the device to Azure Active Directory and complete the
flow.
In the cleanup step, clean up the following files:
Settings.dat in C:\Users\<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\
All the files under the folder
C:\Users\<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Account

Event ID 6065: 80070533 This user can’t sign in because this account is currently disabled
In Event Viewer under the SettingSync/Debug logs, this error can be seen when the user's credentials have expired.
In addition, it can occur when the tenant did not automatically have AzureRMS provisioned.
Recommended action
In the first case, have the user update their credentials and login to the device with the new credentials. To solve
the AzureRMS issue, proceed with the steps listed in KB3193791.

Event ID 1098: Error: 0xCAA5001C Token broker operation failed

In Event Viewer under the AAD/Operational logs, this error may be seen with Event 1104: AAD Cloud AP plugin
call Get token returned error: 0xC000005F. This issue occurs if there are missing permissions or ownership
attributes.
Recommended action
Proceed with the steps listed KB3196528.

Next steps
For an overview, see enterprise state roaming overview.
 Azure Active Directory device management FAQ
9/7/2020 • 17 minutes to read • Edit Online

General FAQ
Q: I registered the device recently. Why can't I see the device under my user info in the Azure portal? Or why is
the device owner marked as N/A for hybrid Azure Active Directory (Azure AD) joined devices?
A: Windows 10 devices that are hybrid Azure AD joined don't show up under USER devices . Use the All devices
view in the Azure portal. You can also use a PowerShell Get-MsolDevice cmdlet.
Only the following devices are listed under USER devices :
All personal devices that aren't hybrid Azure AD joined.
All non-Windows 10 or Windows Server 2016 devices.
All non-Windows devices.

Q: How do I know what the device registration state of the client is?
A: In the Azure portal, go to All devices . Search for the device by using the device ID. Check the value under the
join type column. Sometimes, the device might be reset or reimaged. So it's essential to also check the device
registration state on the device:
For Windows 10 and Windows Server 2016 or later devices, run dsregcmd.exe /status .
For down-level OS versions, run %programFiles%\Microsoft Workplace Join\autoworkplace.exe .
A: For troubleshooting information, see these articles:
Troubleshooting devices using dsregcmd command
Troubleshooting hybrid Azure Active Directory joined Windows 10 and Windows Server 2016 devices
Troubleshooting hybrid Azure Active Directory joined down-level devices

Q: I see the device record under the USER info in the Azure portal. And I see the state as registered on the
device. Am I set up correctly to use Conditional Access?
A: The device join state, shown by deviceID , must match the state on Azure AD and meet any evaluation criteria
for Conditional Access. For more information, see Require managed devices for cloud app access with Conditional
Access.

Q: Why do my users see an error message saying "Your organization has deleted the device" or "Your
organization has disabled the device" on their Windows 10 devices?
A: On Windows 10 devices joined or registered with Azure AD, users are issued a Primary refresh token (PRT)
which enables single sign on. The validity of the PRT is based on the validity of the device itself. Users see this
message if the device is either deleted or disabled in Azure AD without initiating the action from the device itself. A
device can be deleted or disabled in Azure AD one of the following scenarios:
User disables the device from the My Apps portal.
An administrator (or user) deletes or disables the device in the Azure portal or by using PowerShell
Hybrid Azure AD joined only: An administrator removes the devices OU out of sync scope resulting in the
devices being deleted from Azure AD
Upgrading Azure AD connect to the version 1.4.xx.x. Understanding Azure AD Connect 1.4.xx.x and device
disappearance.
See below on how these actions can be rectified.

Q: I disabled or deleted my device in the Azure portal or by using Windows PowerShell. But the local state on
the device says it's still registered. What should I do?
A: This operation is by design. In this case, the device doesn't have access to resources in the cloud. Administrators
can perform this action for stale, lost, or stolen devices to prevent unauthorized access. If this action was
performed unintentionally, you'll need to re-enable or re-register the device as described below
If the device was disabled in Azure AD, an administrator with sufficient privileges can enable it from the
Azure AD portal

NOTE
If you are syncing devices using Azure AD Connect, hybrid Azure AD joined devices will be automatically re-enabled
during the next sync cycle. So, if you need to disable a hybrid Azure AD joined device, you need to disable it from
your on-premises AD

If the device is deleted in Azure AD, you need to re-register the device. To re-register, you must take a
manual action on the device. See below for instructions for re-registration based on the device state.
To re-register hybrid Azure AD joined Windows 10 and Windows Server 2016/2019 devices, take the
following steps:
1. Open the command prompt as an administrator.
2. Enter dsregcmd.exe /debug /leave .
3. Sign out and sign in to trigger the scheduled task that registers the device again with Azure AD.
For down-level Windows OS versions that are hybrid Azure AD joined, take the following steps:
1. Open the command prompt as an administrator.
2. Enter "%programFiles%\Microsoft Workplace Join\autoworkplace.exe /l" .
3. Enter "%programFiles%\Microsoft Workplace Join\autoworkplace.exe /j" .
For Azure AD joined devices Windows 10 devices, take the following steps:
1. Open the command prompt as an administrator
2. Enter dsregcmd /forcerecovery (Note: You need to be an administrator to perform this action).
3. Click "Sign in" in the dialog that opens up and continue with the sign in process.
4. Sign out and sign in back to the device to complete the recovery.
For Azure AD registered Windows 10 devices, take the following steps:
1. Go to Settings > Accounts > Access Work or School .
2. Select the account and select Disconnect .
3. Click on "+ Connect" and register the device again by going through the sign in process.

Q: Why do I see duplicate device entries in the Azure portal?

A:
For Windows 10 and Windows Server 2016, repeated tries to unjoin and rejoin the same device might cause
duplicate entries.
Each Windows user who uses Add Work or School Account creates a new device record with the same
device name.
For down-level Windows OS versions that are on-premises Azure Directory domain joined, automatic
registration creates a new device record with the same device name for each domain user who signs in to the
 device.
An Azure AD joined machine that's wiped, reinstalled, and rejoined with the same name shows up as another
record with the same device name.

Q: Does Windows 10 device registration in Azure AD support TPMs in FIPS mode?

A: Windows 10 device registration only supported for FIPS-compliant TPM 2.0 and not supported for TPM 1.2. If
your devices have FIPS-compliant TPM 1.2, you must disable them before proceeding with Azure AD join or
Hybrid Azure AD join. Microsoft does not provide any tools for disabling FIPS mode for TPMs as it is dependent
on the TPM manufacturer. Contact your hardware OEM for support.

Q: Why can a user still access resources from a device I disabled in the Azure por tal?
A: It takes up to an hour for a revoke to be applied from the time the Azure AD device is marked as disabled.

NOTE
For enrolled devices, we recommend that you wipe the device to make sure users can't access the resources. For more
information, see What is device enrollment?.

Q: Why are there devices marked as "Pending" under the REGISTERED column in the Azure portal?
A : Pending indicates that the device is not registered. This state indicates that a device has been synchronized
using Azure AD connect from an on-premises AD and is ready for device registration. These devices have the JOIN
TYPE set to "Hybrid Azure AD joined". Learn more on how to plan your hybrid Azure Active Directory join
implementation.

NOTE
A device can also change from having a registered state to "Pending"
If a device is deleted from Azure AD first and re-synchronized from an on-premises AD.
If a device is removed from a sync scope on Azure AD Connect and added back.
In both cases, you must re-register the device manually on each of these devices. To review whether the device was
previously registered, you can troubleshoot devices using the dsregcmd command.

Azure AD join FAQ

Q: How do I unjoin an Azure AD joined device locally on the device?
A: For pure Azure AD joined devices, make sure you have an offline local administrator account or create one. You
can't sign in with any Azure AD user credentials. Next, go to Settings > Accounts > Access Work or School .
Select your account and select Disconnect . Follow the prompts and provide the local administrator credentials
when prompted. Reboot the device to finish the unjoin process.

Q: Can my users' sign in to Azure AD joined devices that are deleted or disabled in Azure AD?
A: Yes. Windows has a cached username and password capability that allows users who signed in previously to
access the desktop quickly even without network connectivity.
When a device is deleted or disabled in Azure AD, it's not known to the Windows device. So users who signed in
previously continue to access the desktop with the cached username and password. But as the device is deleted or
disabled, users can't access any resources protected by device-based Conditional Access.
Users who didn't sign in previously can't access the device. There's no cached username and password enabled for
them.

Q: Can a disabled or deleted user sign in to an Azure AD joined devices

A: Yes, but only for a limited time. When a user is deleted or disabled in Azure AD, it's not immediately known to
the Windows device. So users who signed in previously can access the desktop with the cached username and
password.
Typically, the device is aware of the user state in less than four hours. Then Windows blocks those users' access to
the desktop. As the user is deleted or disabled in Azure AD, all their tokens are revoked. So they can't access any
resources.
Deleted or disabled users who didn't sign in previously can't access a device. There's no cached username and
password enabled for them.

Q: Why do my users have issues on Azure AD joined devices after changing their UPN?
A: Currently, UPN changes are not fully supported on Azure AD joined devices. So their authentication with Azure
AD fails after their UPN changes. As a result, users have SSO and Conditional Access issues on their devices. At
this time, users need to sign in to Windows through the "Other user" tile using their new UPN to resolve this issue.
We are currently working on addressing this issue. However, users signing in with Windows Hello for Business do
not face this issue.
UPN changes are supported with Windows 10 2004 update. Users on devices with this update will not have any
issues after changing their UPNs

Q: My users can't search printers from Azure AD joined devices. How can I enable printing from those devices?
A: To deploy printers for Azure AD joined devices, see Deploy Windows Server Hybrid Cloud Print with Pre-
Authentication. You need an on-premises Windows Server to deploy hybrid cloud print. Currently, cloud-based
print service isn't available.

Q: How do I connect to a remote Azure AD joined device?

A: See Connect to remote Azure Active Directory-joined PC.

Q: Why do my users see You can't get there from here?

A: Did you configure certain Conditional Access rules to require a specific device state? If the device doesn't meet
the criteria, users are blocked, and they see that message. Evaluate the Conditional Access policy rules. Make sure
the device meets the criteria to avoid the message.

Q: Why don't some of my users get Azure Multi-Factor Authentication prompts on Azure AD joined devices?
A: A user might join or register a device with Azure AD by using Multi-Factor Authentication. Then the device itself
becomes a trusted second factor for that user. Whenever the same user signs in to the device and accesses an
application, Azure AD considers the device as a second factor. It enables that user to seamlessly access applications
without additional Multi-Factor Authentication prompts.
This behavior:
Is applicable to Azure AD joined and Azure AD registered devices - but not for hybrid Azure AD joined devices.
Isn't applicable to any other user who signs in to that device. So all other users who access that device get a
Multi-Factor Authentication challenge. Then they can access applications that require Multi-Factor
Authentication.

Q: Why do I get a username or password is incorrect message for a device I just joined to Azure AD?
A: Common reasons for this scenario are as follows:
Your user credentials are no longer valid.
Your computer can't communicate with Azure Active Directory. Check for any network connectivity issues.
Federated sign-ins require your federation server to support WS-Trust endpoints that are enabled and
accessible.
You enabled pass-through authentication. So your temporary password needs to be changed when you sign in.

Q: Why do I see the Oops… an error occurred! dialog when I try to Azure AD join my PC?
A: This error happens when you set up Azure Active Directory enrollment with Intune. Make sure that the user
who tries to Azure AD join has the correct Intune license assigned. For more information, see Set up enrollment
for Windows devices.

Q: Why did my attempt to Azure AD join a PC fail, although I didn't get any error information?
A: A likely cause is that you signed in to the device by using the local built-in administrator account. Create a
different local account before you use Azure Active Directory join to finish the setup.

Q:What are the MS -Organization-P2P-Access certificates present on our Windows 10 devices?

A: The MS-Organization-P2P-Access certificates are issued by Azure AD to both, Azure AD joined and hybrid
Azure AD joined devices. These certificates are used to enable trust between devices in the same tenant for remote
desktop scenarios. One certificate is issued to the device and another is issued to the user. The device certificate is
present in Local Computer\Personal\Certificates and is valid for one day. This certificate is renewed (by issuing a
new certificate) if the device is still active in Azure AD. The user certificate is present in
Current User\Personal\Certificates and this certificate is also valid for one day, but it is issued on-demand when
a user attempts a remote desktop session to another Azure AD joined device. It is not renewed on expiry. Both
these certificates are issued using the MS-Organization-P2P-Access certificate present in the
Local Computer\AAD Token Issuer\Certificates . This certificate is issued by Azure AD during device registration.

Q:Why do I see multiple expired certificates issued by MS -Organization-P2P-Access on our Windows 10

devices? How can I delete them?
A: There was an issue identified on Windows 10 version 1709 and lower where expired MS-Organization-P2P-
Access certificates continued to exist on the computer store because of cryptographic issues. Your users could face
issues with network connectivity, if you are using any VPN clients (for example, Cisco AnyConnect) that cannot
handle the large number of expired certificates. This issue was fixed in Windows 10 1803 release to automatically
delete any such expired MS-Organization-P2P-Access certificates. You can resolve this issue by updating your
devices to Windows 10 1803. If you are unable to update, you can delete these certificates without any adverse
impact.

Hybrid Azure AD join FAQ

Q: How do I unjoin a Hybrid Azure AD joined device locally on the device?
A: For hybrid Azure AD joined devices, make sure to turn off automatic registration. Then the scheduled task
doesn't register the device again. Next, open a command prompt as an administrator and enter
dsregcmd.exe /debug /leave . Or run this command as a script across several devices to unjoin in bulk.

Q: Where can I find troubleshooting information to diagnose hybrid Azure AD join failures?
A: For troubleshooting information, see these articles:
Troubleshooting hybrid Azure Active Directory joined Windows 10 and Windows Server 2016 devices
Troubleshooting hybrid Azure Active Directory joined down-level devices
Q: Why do I see a duplicate Azure AD registered record for my Windows 10 hybrid Azure AD joined device in
the Azure AD devices list?
A: When your users add their accounts to apps on a domain-joined device, they might be prompted with Add
account to Windows? If they enter Yes on the prompt, the device registers with Azure AD. The trust type is
marked as Azure AD registered. After you enable hybrid Azure AD join in your organization, the device also gets
hybrid Azure AD joined. Then two device states show up for the same device.
Hybrid Azure AD join takes precedence over the Azure AD registered state. So your device is considered hybrid
Azure AD joined for any authentication and Conditional Access evaluation. You can safely delete the Azure AD
registered device record from the Azure AD portal. Learn to avoid or clean up this dual state on the Windows 10
machine.

Q: Why do my users have issues on Windows 10 hybrid Azure AD joined devices after changing their UPN?
A: Currently UPN changes are not fully supported with hybrid Azure AD joined devices. While users can sign in to
the device and access their on-premises applications, authentication with Azure AD fails after a UPN change. As a
result, users have SSO and Conditional Access issues on their devices. At this time, you need to unjoin the device
from Azure AD (run "dsregcmd /leave" with elevated privileges) and rejoin (happens automatically) to resolve the
issue. We are currently working on addressing this issue. However, users signing in with Windows Hello for
Business do not face this issue.
UPN changes are supported with Windows 10 2004 update. Users on devices with this update will not have any
issues after changing their UPNs

Q: Do Windows 10 hybrid Azure AD joined devices require line of sight to the domain controller to get access
to cloud resources?
A: No, except when the user's password is changed. After Windows 10 hybrid Azure AD join is complete, and the
user has signed in at least once, the device doesn't require line of sight to the domain controller to access cloud
resources. Windows 10 can get single sign-on to Azure AD applications from anywhere with an internet
connection, except when a password is changed. Users who sign in with Windows Hello for Business continue to
get single sign-on to Azure AD applications even after a password change, even if they don't have line of sight to
their domain controller.

Q: What happens if a user changes their password and tries to login to their Windows 10 hybrid Azure AD
joined device outside the corporate network?
A: If a password is changed outside the corporate network (for example, by using Azure AD SSPR), then the user
sign in with the new password will fail. For hybrid Azure AD joined devices, on-premises Active Directory is the
primary authority. When a device does not have line of sight to the domain controller, it is unable to validate the
new password. So, user needs to establish connection with the domain controller (either via VPN or being in the
corporate network) before they're able to sign in to the device with their new password. Otherwise, they can only
sign in with their old password because of cached sign in capability in Windows. However, the old password is
invalidated by Azure AD during token requests and hence, prevents single sign-on and fails any device-based
Conditional Access policies. This issue doesn't occur if you use Windows Hello for Business.

Azure AD register FAQ

Q: How do I remove an Azure AD registered state for a device locally?
A:
For Windows 10 Azure AD registered devices, Go to Settings > Accounts > Access Work or School . Select
your account and select Disconnect . Device registration is per user profile on Windows 10.
For iOS and Android, you can use the Microsoft Authenticator application Settings > Device Registration
and select Unregister device .
 For macOS, you can use the Microsoft Intune Company Portal application to unenroll the device from
management and remove any registration.

Q: How can I block users from adding additional work accounts (Azure AD registered) on my corporate
Windows 10 devices?
A: Enable the following registry to block your users from adding additional work accounts to your corporate
domain joined, Azure AD joined, or hybrid Azure AD joined Windows 10 devices. This policy can also be used to
block domain joined machines from inadvertently getting Azure AD registered with the same user account.
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, "BlockAADWorkplaceJoin"=dword:00000001

Q: Can I register Android or iOS BYOD devices?

A: Yes, but only with the Azure device registration service and for hybrid customers. It's not supported with the
on-premises device registration service in Active Directory Federation Services (AD FS).

Q: How can I register a macOS device?

A: Take the following steps:
1. Create a compliance policy
2. Define a Conditional Access policy for macOS devices
Remarks:
The users included in your Conditional Access policy need a supported version of Office for macOS to access
resources.
During the first access try, your users are prompted to enroll the device by using the company portal.

Next steps
Learn more about Azure AD registered devices
Learn more about Azure AD joined devices
Learn more about hybrid Azure AD joined devices
 Settings and data roaming FAQ
9/7/2020 • 10 minutes to read • Edit Online

This article answers some questions IT administrators might have about settings and app data sync.

What data roams?

Windows settings : the PC settings that are built into the Windows operating system. Generally, these are settings
that personalize your PC, and they include the following broad categories:
Theme, which includes features such as desktop theme and taskbar settings.
Internet Explorer settings, including recently opened tabs and favorites.
Microsoft Edge browser settings, such as favorites and reading list.
Passwords, including Internet passwords, Wi-Fi profiles, and others.
Language preferences, which include settings for keyboard layouts, system language, date and time, and more.
Ease of access features, such as high-contrast theme, Narrator, and Magnifier.
Other Windows settings, such as mouse settings.

NOTE
This article applies to the Microsoft Edge Legacy HTML-based browser launched with Windows 10 in July 2015. The article
does not apply to the new Microsoft Edge Chromium-based browser released on January 15, 2020. For more information
on the Sync behavior for the new Microsoft Edge, see the article Microsoft Edge Sync.

Application data : Universal Windows apps can write settings data to a roaming folder, and any data written to
this folder will automatically be synced. It’s up to the individual app developer to design an app to take advantage
of this capability. For more information about how to develop a Universal Windows app that uses roaming, see the
appdata storage API and the Windows 8 appdata roaming developer blog.

What account is used for settings sync?

In Windows 8.1, settings sync always used consumer Microsoft accounts. Enterprise users had the ability to
connect a Microsoft account to their Active Directory domain account to gain access to settings sync. In Windows
10, this connected Microsoft account functionality is being replaced with a primary/secondary account framework.
The primary account is defined as the account used to sign in to Windows. This can be a Microsoft account, an
Azure Active Directory (Azure AD) account, an on-premises Active Directory account, or a local account. In addition
to the primary account, Windows 10 users can add one or more secondary cloud accounts to their device. A
secondary account is generally a Microsoft account, an Azure AD account, or some other account such as Gmail or
Facebook. These secondary accounts provide access to additional services such as single sign-on and the
Windows Store, but they are not capable of powering settings sync.
In Windows 10, only the primary account for the device can be used for settings sync (see How do I upgrade from
Microsoft account settings sync in Windows 8 to Azure AD settings sync in Windows 10?).
Data is never mixed between the different user accounts on the device. There are two rules for settings sync:
Windows settings will always roam with the primary account.
App data will be tagged with the account used to acquire the app. Only apps tagged with the primary account
will sync. App ownership tagging is determined when an app is side-loaded through the Windows Store or
 mobile device management (MDM).
If an app’s owner cannot be identified, it will roam with the primary account. If a device is upgraded from Windows
8 or Windows 8.1 to Windows 10, all the apps will be tagged as acquired by the Microsoft account. This is because
most users acquire apps through the Windows Store, and there was no Windows Store support for Azure AD
accounts prior to Windows 10. If an app is installed via an offline license, the app will be tagged using the primary
account on the device.

NOTE
Windows 10 devices that are enterprise-owned and are connected to Azure AD can no longer connect their Microsoft
accounts to a domain account. The ability to connect a Microsoft account to a domain account and have all the user's data
sync to the Microsoft account (that is, the Microsoft account roaming via the connected Microsoft account and Active
Directory functionality) is removed from Windows 10 devices that are joined to a connected Active Directory or Azure AD
environment.

How do I upgrade from Microsoft account settings sync in Windows 8

to Azure AD settings sync in Windows 10?
If you are joined to the Active Directory domain running Windows 8.1 with a connected Microsoft account, you will
sync settings through your Microsoft account. After upgrading to Windows 10, you will continue to sync user
settings via Microsoft account as long as you are a domain-joined user and the Active Directory domain does not
connect with Azure AD.
If the on-premises Active Directory domain does connect with Azure AD, your device will attempt to sync settings
using the connected Azure AD account. If the Azure AD administrator does not enable Enterprise State Roaming,
your connected Azure AD account will stop syncing settings. If you are a Windows 10 user and you sign in with an
Azure AD identity, you will start syncing windows settings as soon as your administrator enables settings sync via
Azure AD.
If you stored any personal data on your corporate device, you should be aware that Windows OS and application
data will begin syncing to Azure AD. This has the following implications:
Your personal Microsoft account settings will drift apart from the settings on your work or school Azure AD
accounts. This is because the Microsoft account and Azure AD settings sync are now using separate accounts.
Personal data such as Wi-Fi passwords, web credentials, and Internet Explorer favorites that were previously
synced via a connected Microsoft account will be synced via Azure AD.

How do Microsoft account and Azure AD Enterprise State Roaming

interoperability work?
In the November 2015 or later releases of Windows 10, Enterprise State Roaming is only supported for a single
account at a time. If you sign in to Windows by using a work or school Azure AD account, all data will sync via
Azure AD. If you sign in to Windows by using a personal Microsoft account, all data will sync via the Microsoft
account. Universal appdata will roam using only the primary sign-in account on the device, and it will roam only if
the app’s license is owned by the primary account. Universal appdata for the apps owned by any secondary
accounts will not be synced.

Do settings sync for Azure AD accounts from multiple tenants?

When multiple Azure AD accounts from different Azure AD tenants are on the same device, you must update the
device's registry to communicate with the Azure Rights Management service for each Azure AD tenant.
1. Find the GUID for each Azure AD tenant. Open the Azure portal and select an Azure AD tenant. The GUID for the
 tenant is on the Properties page for the selected tenant
(https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties), labeled
Director y ID .
2. After you have the GUID, you will need to add the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\SettingSync\WinMSIPC<tenant ID
GUID> . From the tenant ID GUID key, create a new Multi-String value (REG-MULTI-SZ) named
AllowedRMSSer verUrls . For its data, specify the licensing distribution point URLs of the other Azure tenants
that the device accesses.
3. You can find the licensing distribution point URLs by running the Get-AadrmConfiguration cmdlet from the
AADRM module. If the values for the LicensingIntranetDistributionPointUrl and
LicensingExtranetDistributionPointUrl are different, specify both values. If the values are the same, specify
the value just once.

What are the roaming settings options for existing Windows desktop
applications?
Roaming only works for Universal Windows apps. There are two options available for enabling roaming on an
existing Windows desktop application:
The Desktop Bridge helps you bring your existing Windows desktop apps to the Universal Windows Platform.
From here, minimal code changes will be required to take advantage of Azure AD app data roaming. The
Desktop Bridge provides your apps with an app identity, which is needed to enable app data roaming for
existing desktop apps.
User Experience Virtualization (UE-V) helps you create a custom settings template for existing Windows
desktop apps and enable roaming for Win32 apps. This option does not require the app developer to change
code of the app. UE-V is limited to on-premises Active Directory roaming for customers who have purchased
the Microsoft Desktop Optimization Pack.
Administrators can configure UE-V to roam Windows desktop app data by changing roaming of Windows OS
settings and Universal app data through UE-V group policies, including:
Roam Windows settings group policy
Do not synchronize Windows Apps group policy
Internet Explorer roaming in the applications section
In the future, Microsoft may investigate ways to make UE-V deeply integrated into Windows and extend UE-V to
roam settings through the Azure AD cloud.

Can I store synced settings and data on-premises?

Enterprise State Roaming stores all synced data in the Microsoft cloud. UE-V offers an on-premises roaming
solution.

Who owns the data that’s being roamed?

The enterprises own the data roamed via Enterprise State Roaming. Data is stored in an Azure datacenter. All user
data is encrypted both in transit and at rest in the cloud using the Azure Rights Management service from Azure
Information Protection. This is an improvement compared to Microsoft account-based settings sync, which
encrypts only certain sensitive data such as user credentials before it leaves the device.
Microsoft is committed to safeguarding customer data. An enterprise user’s settings data is automatically
encrypted by the Azure Rights Management service before it leaves a Windows 10 device, so no other user can
read this data. If your organization has a paid subscription for the Azure Rights Management service, you can use
other protection features, such as track and revoke documents, automatically protect emails that contain sensitive
information, and manage your own keys (the "bring your own key" solution, also known as BYOK). For more
information about these features and how this protection service works, see What is Azure Rights Management.

Can I manage sync for a specific app or setting?

In Windows 10, there is no MDM or Group Policy setting to disable roaming for an individual application. Tenant
administrators can disable appdata sync for all apps on a managed device, but there is no finer control at a per-
app or within-app level.

How can I enable or disable roaming?

In the Settings app, go to Accounts > Sync your settings . From this page, you can see which account is being
used to roam settings, and you can enable or disable individual groups of settings to be roamed.

What is Microsoft’s recommendation for enabling roaming in Windows

10?
Microsoft has a few different settings roaming solutions available, including Roaming User Profiles, UE-V, and
Enterprise State Roaming. Microsoft is committed to making an investment in Enterprise State Roaming in future
versions of Windows. If your organization is not ready or comfortable with moving data to the cloud, then we
recommend that you use UE-V as your primary roaming technology. If your organization requires roaming
support for existing Windows desktop applications but is eager to move to the cloud, we recommend that you use
both Enterprise State Roaming and UE-V. Although UE-V and Enterprise State Roaming are very similar
technologies, they are not mutually exclusive. They complement each other to help ensure that your organization
provides the roaming services that your users need.
When using both Enterprise State Roaming and UE-V, the following rules apply:
Enterprise State Roaming is the primary roaming agent on the device. UE-V is being used to supplement the
“Win32 gap.”
UE-V roaming for Windows settings and modern UWP app data should be disabled when using the UE-V
group policies. These are already covered by Enterprise State Roaming.

How does Enterprise State Roaming support virtual desktop

infrastructure (VDI)?
Enterprise State Roaming is supported on Windows 10 client SKUs, but not on server SKUs. If a client VM is hosted
on a hypervisor machine and you remotely sign in to the virtual machine, your data will roam. If multiple users
share the same OS and users remotely sign in to a server for a full desktop experience, roaming might not work.
The latter session-based scenario is not officially supported.

What happens when my organization purchases a subscription that

includes Azure Rights Management after using roaming?
If your organization is already using roaming in Windows 10 with the Azure Rights Management limited-use free
subscription, purchasing a paid subscription that includes the Azure Rights Management protection service will
not have any impact on the functionality of the roaming feature, and no configuration changes will be required by
your IT administrator.

Known issues
See the documentation in the troubleshooting section for a list of known issues.
Next steps
For an overview, see enterprise state roaming overview
 Enforce TLS 1.2 for the Azure AD Registration Service
9/7/2020 • 2 minutes to read • Edit Online

The Azure Active Directory (Azure AD) Device Registration Service is used to connect devices to the cloud with a
device identity. The Azure AD Device Registration Service currently supports using Transport Layer Security (TLS)
1.2 for communications with Azure. To ensure security and best-in-class encryption, Microsoft recommends
disabling TLS 1.0 and 1.1. This document will provide information on how to ensure machines used to complete
registration and communicate with the Azure AD Device Registration Service use TLS 1.2.
The TLS protocol version 1.2 is a cryptography protocol that is designed to provide secure communications. The
TLS protocol aims primarily to provide privacy and data integrity. TLS has gone through many iterations with
version 1.2 being defined in RFC 5246 (external link).
Current analysis of connections shows little TLS 1.1 and 1.0 usage, but we are providing this information so that
you can update any affected clients or servers as necessary before support for TLS 1.1 and 1.0 ends. If you are
using any on-premises infrastructure for hybrid scenarios or Active Directory Federation Services (AD FS), make
sure that the infrastructure can support both inbound and outbound connections that use TLS 1.2.

Update Windows servers

For Windows servers that use the Azure AD Device Registration Service or act as proxies, use the following steps to
ensure TLS 1.2 is enabled:

IMPORTANT
After you have updated the registry, you must restart the Windows server for the changes to take effect.

Enable TLS 1.2

Ensure the following registry strings are configured as shown:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001

Update non-Windows proxies

Any machines that act as proxies between devices and the Azure AD Device Registration Service must ensure that
TLS 1.2 is enabled. Follow your vendor's guidance to ensure support.

Update AD FS servers
Any AD FS servers used to communicate with the Azure AD Device Registration Service must ensure that TLS 1.2 is
enabled. See Managing SSL/TLS Protocols and Cipher Suites for AD FS for information on how to enable/verify this
configuration.

Client updates
Since all client-server and browser-server combinations must use TLS 1.2 to connect with the Azure AD Device
Registration Service, you may need to update these devices.
The following clients are known to be unable to support TLS 1.2. Update your clients to ensure uninterrupted
access.
Android version 4.3 and earlier
Firefox version 5.0 and earlier
Internet Explorer versions 8-10 on Windows 7 and earlier
Internet Explorer 10 on Windows Phone 8.0
Safari version 6.0.4 on OS X 10.8.4 and earlier

Next steps
TLS/SSL overview (Schannel SSP)
 Group Policy and MDM settings
9/7/2020 • 2 minutes to read • Edit Online

Use these group policy and mobile device management (MDM) settings only on corporate-owned devices because
these policies are applied to the user’s entire device. Applying an MDM policy to disable settings sync for a
personal, user-owned device will negatively impact the use of that device. Additionally, other user accounts on the
device will also be affected by the policy.
Enterprises that want to manage roaming for personal (unmanaged) devices can use the Azure portal to enable or
disable roaming, rather than using Group Policy or MDM. The following tables describe the policy settings
available.

NOTE
This article applies to the Microsoft Edge Legacy HTML-based browser launched with Windows 10 in July 2015. The article
does not apply to the new Microsoft Edge Chromium-based browser released on January 15, 2020. For more information
on the Sync behavior for the new Microsoft Edge, see the article Microsoft Edge Sync.

MDM settings
The MDM policy settings apply to both Windows 10 and Windows 10 Mobile. Windows 10 Mobile support exists
only for Microsoft account based roaming via user’s OneDrive account. Refer to Devices and endpoints for details
on what devices are supported for Azure AD-based syncing.

NAME DESC RIP T IO N

Allow Microsoft Account Connection Allows users to authenticate using a Microsoft account on the
device

Allow Sync My Settings Allows users to roam Windows settings and app data;
Disabling this policy will disable sync as well as backups on
mobile devices

Group policy settings

The group policy settings apply to Windows 10 devices that are joined to an Active Directory domain. The table
also includes legacy settings that would appear to manage sync settings, but that do not work for Enterprise State
Roaming for Windows 10, which are noted with ‘Do not use’ in the description.
These settings are located at:
Computer Configuration > Administrative Templates > Windows Components > Sync your settings

NAME DESC RIP T IO N

Accounts: Block Microsoft Accounts This policy setting prevents users from adding new Microsoft
accounts on this computer

Do not sync Prevents users to roam Windows settings and app data

Do not sync personalize Disables syncing of the Themes group

 NAME DESC RIP T IO N

Do not sync browser settings Disables syncing of the Internet Explorer group

Do not sync passwords Disables syncing of Passwords group

Do not sync other Windows settings Disables syncing of Other Windows settings group

Do not sync desktop personalization Do not use; has no effect

Do not sync on metered connections Disables roaming on metered connections, such as cellular 3G

Do not sync apps Do not use; has no effect

Do not sync app settings Disables roaming of app data

Do not sync start settings Do not use; has no effect

Next steps
For an overview, see enterprise State Roaming overview.
 Windows 10 roaming settings reference
9/7/2020 • 8 minutes to read • Edit Online

The following is a list of the settings that will be roamed or backed up in Windows 10.

Devices and endpoints

See the following table for a summary of the devices and account types that are supported by the sync, backup,
and restore framework in Windows 10.

A C C O UN T T Y P E A N D O P ERAT IO N DESK TO P M O B IL E

Azure Active Directory: sync Yes No

Azure Active Directory: backup/restore No No

Microsoft account: sync Yes Yes

Microsoft account: backup/restore No Yes

What is backup?
Windows settings generally sync by default, but some settings are only backed up, such as the list of installed
applications on a device. Backup is for mobile devices only and currently not available for Enterprise State
Roaming users. Backup uses a Microsoft account and stores the settings and application data into OneDrive. If a
user disables sync on the device using the Settings app, application data that normally syncs becomes backup only.
Backup data can only be accessed through the restore operation during the first run experience of a new device.
Backups can be disabled via the device settings, and can be managed and deleted through the user’s OneDrive
account.

Windows Settings overview

The following settings groups are available for end users to enable/disable settings sync on Windows 10 devices.
Theme: desktop background, user tile, taskbar position, etc.
Internet Explorer Settings: browsing history, typed URLs, favorites, etc.
Passwords: Windows credential manager, including Wi-Fi profiles
Language Preferences: spelling dictionary, system language settings
Ease of Access: narrator, on-screen keyboard, magnifier
Other Windows Settings: see Windows Settings details
Microsoft Edge browser setting: Microsoft Edge favorites, reading list, and other settings
 NOTE
This article applies to the Microsoft Edge Legacy HTML-based browser launched with Windows 10 in July 2015. The article
does not apply to the new Microsoft Edge Chromium-based browser released on January 15, 2020. For more information
on the Sync behavior for the new Microsoft Edge, see the article Microsoft Edge Sync.

Microsoft Edge browser setting group (favorites, reading list) syncing can be enabled or disabled by end users
through Microsoft Edge browser Settings menu option.

For Windows 10 version 1803 or later, Internet Explorer setting group (favorites, typed URLs) syncing can be
enabled or disabled by end users through Internet Explorer Settings menu option.
Windows Settings details
In the following table, Other entries in the Settings Group column refer to settings that can be disabled by going to
Settings > Accounts > Sync your settings > Other Windows settings.
Internal entries in the Settings Group column refer to settings and apps that can only be disabled from syncing
within the app itself or by disabling sync for the entire device using mobile device management (MDM) or Group
Policy settings. Settings that don't roam or sync will not belong to a group.

SET T IN GS DESK TO P M O B IL E GRO UP

Accounts : account picture sync X Theme

Accounts : other account X X

settings

Advanced mobile X X Passwords

broadband : Internet
connection sharing network
name (enables
autodiscovery of mobile Wi-
Fi hotspots via Bluetooth)

App data : individual apps sync backup sync backup internal

can sync data

App list : list of installed X backup Other

apps

Bluetooth : all Bluetooth X X

settings

Command prompt : sync X internal

Command prompt
"Defaults" settings

Credentials : Credential sync sync password

Locker
SET T IN GS DESK TO P M O B IL E GRO UP

Date, Time, and Region : sync sync language

automatic time (Internet
time sync)

Date, Time, and Region : sync X language

24-hour clock

Date, Time, and Region : sync X language

date and time

Date, Time, and Region : X language

time zone

Date, Time, and Region : sync X language

daylight savings time

Date, Time, and Region : sync X language

country/region

Date, Time, and Region : sync X language

first day of week

Date, Time, and Region : sync X language

region format (locale)

Date, Time, and Region : sync X language

short date

Date, Time, and Region : sync X language

long date

Date, Time, and Region : sync X language

short time

Date, Time, and Region : sync X language

long time

Desktop personalization : sync X Theme

desktop Theme
(background, system color,
default system sounds,
screen saver)

Desktop personalization : sync X Theme

slideshow wallpaper

Desktop personalization : sync X Theme

taskbar settings (position,
auto-hide, etc.)

Desktop personalization : X backup

start screen layout
SET T IN GS DESK TO P M O B IL E GRO UP

Devices : shared printers X X other

you've connected to

Microsoft Edge browser : sync sync internal

reading list

Microsoft Edge browser : sync sync internal

favorites

Microsoft Edge browser : sync sync internal

top sites [1]

Microsoft Edge browser : sync sync internal

typed URLs [1]

Microsoft Edge browser : sync sync internal

favorites bar settings [1]

Microsoft Edge browser : sync sync internal

show the home button [1]

Microsoft Edge browser : sync sync internal

block pop-ups [1]

Microsoft Edge browser : sync sync internal

ask me what to do with each
download [1]

Microsoft Edge browser : sync sync internal

offer to save passwords [1]

Microsoft Edge browser : sync sync internal

send do not track requests
[1]

Microsoft Edge browser : sync sync internal

save form entries [1]

Microsoft Edge browser : sync sync internal

show search and site
suggestions as I type [1]

Microsoft Edge browser : sync sync internal

cookies preference [1]

Microsoft Edge browser : sync sync internal

let sites save protected
media licenses on my device
[1]

Microsoft Edge browser : sync sync internal

screen reader setting [1]

High Contrast : On or Off sync X ease of access

SET T IN GS DESK TO P M O B IL E GRO UP

High contrast : Theme sync X ease of access

settings

Internet Explorer : open sync sync Internet Explorer

tabs (URL and title)

Internet Explorer : reading sync sync Internet Explorer

list

Internet Explorer : typed sync sync Internet Explorer

URLs

Internet Explorer : sync sync Internet Explorer

browsing history

Internet Explorer : sync sync Internet Explorer

favorites

Internet Explorer : sync sync Internet Explorer

excluded URLs

Internet Explorer : home sync sync Internet Explorer

pages

Internet Explorer : domain sync sync Internet Explorer

suggestions

Keyboard : users can turn sync X ease of access

on/off on-screen keyboard

Keyboard : turn on sticky sync X ease of access

yes (off by default)

Keyboard : turn on filter sync X ease of access

keys (off by default)

Keyboard : turn on toggle sync X ease of access

keys (off by default)

Internet Explorer : domain sync X Language

Language: Chinese (CHS)
QWERTY - enable self-
learning

Language : CHS QWERTY - sync X Language

enable dynamic candidate
ranking

Language : CHS QWERTY - sync X Language

char-set Simplified Chinese

Language : CHS QWERTY - sync X Language

char-set Traditional Chinese
SET T IN GS DESK TO P M O B IL E GRO UP

Language : CHS QWERTY - sync backup Language

fuzzy pinyin

Language : CHS QWERTY - sync backup Language

fuzzy pairs

Language : CHS QWERTY - sync X Language

full pinyin

Language : CHS QWERTY - sync X Language

double pinyin

Language : CHS QWERTY - sync X Language

reading auto correction

Language : CHS QWERTY - sync X Language

C/E switch key, shift

Language : CHS QWERTY - sync X Language

C/E switch key, Ctrl

Language : CHS WUBI - sync X Language

single character input mode

Language : CHS WUBI - sync X Language

show the remaining coding
of the candidate

Language : CHS WUBI - sync X Language

beep when 4-coding is
invalid

Language : CHT Bopomofo sync X Language

- include CJK Ext-A

Language : Japanese IME - sync sync Language

predictive typing and
custom words

Language : Korean (KOR) X X Language

IME

Language : handwriting X X Language

recognition

Language : language profile sync backup Language

Language : spellcheck - sync backup Language

autocorrect and highlight
misspellings

Language : list of keyboards sync backup Language

SET T IN GS DESK TO P M O B IL E GRO UP

Lock Screen : all lock screen X X

settings

Magnifier : on or off X X Ease of access

(master toggle)

Magnifier : turn inversion sync X Ease of access

color on or off (off by
default)

Magnifier : tracking - follow sync X Ease of access

the keyboard focus

Magnifier : tracking - follow sync X Ease of access

the mouse cursor

Magnifier : start when users sync X Ease of access

sign in (off by default)

Mouse : change the size of sync X other

mouse cursor

Mouse : change the color of sync X other

mouse cursor

Mouse : all other settings X X

Narrator : quick launch sync X Ease of access

Narrator : users can change sync X Ease of access

Narrator speaking pitch

Narrator : users can turn on sync X Ease of access

or off Narrator reading hints
for common items (on by
default)

Narrator : users can turn on sync X Ease of access

or off whether they can hear
typed characters (on by
default)

Narrator : users can turn on sync X Ease of access

or off whether they can hear
typed words (on by default)

Narrator : have insert sync X Ease of access

cursor following Narrator
(on by default)

Narrator : enable visual sync X Ease of access

highlighting of Narrator
cursor (on by default)
SET T IN GS DESK TO P M O B IL E GRO UP

Narrator : play audio cues sync X Ease of access

(on by default)

Narrator : activate keys on sync X Ease of access

the touch keyboard when
you lift your finger (off by
default)

Ease of access : set the sync X Ease of access

thickness of the blinking
cursor

Ease of access : remove sync X Ease of access

background images (off by
default)

Power and Sleep : all X X

settings

Star t screen X sync Theme

personalization : accent
color (phone only)

Typing : spelling dictionary sync backup Language

Typing : autocorrect sync backup Language

misspelled word

Typing : highlight misspelled sync backup Language

words

Typing : show text sync backup Language

suggestions as I type

Typing : add a space after I sync backup Language

choose a text suggestion

Typing : add a period after I sync backup Language

double-tap the spacebar

Typing : capitalize the first sync backup Language

letter of each sentence

Typing : use all uppercase sync backup Language

letters when I double-tap
shift key

Typing : play key sounds as I sync backup Language

type

Typing : personalization data sync backup Language

for touch keyboard
 SET T IN GS DESK TO P M O B IL E GRO UP

Wi-Fi: Wi-Fi profiles (only sync sync Passwords

WPA)
Fo o tn o te 1

Minimum supported OS version of Windows Creators Update (Build 15063).

Next steps
For an overview, see enterprise state roaming overview.
 What's new in Azure Active Directory?
9/7/2020 • 53 minutes to read • Edit Online

Get notified about when to revisit this page for updates by copying and pasting this URL:
https://docs.microsoft.com/api/search/rss?search=%22Release+notes+-+Azure+Active+Directory%22&locale=en-us
into your feed reader.

Azure AD receives improvements on an ongoing basis. To stay up to date with the most recent developments, this
article provides you with information about:
The latest releases
Known issues
Bug fixes
Deprecated functionality
Plans for changes
This page is updated monthly, so revisit it regularly. If you're looking for items older than six months, you can find
them in Archive for What's new in Azure Active Directory.

August 2020
Updates to Azure Multi-Factor Authentication Server firewall requirements
Type: Plan for change
Ser vice categor y: MFA
Product capability: Identity Security & Protection
Starting 1 October 2020, Azure MFA Server firewall requirements will require additional IP ranges.
If you have outbound firewall rules in your organization, update the rules so that your MFA servers can
communicate with all the necessary IP ranges. The IP ranges are documented in Azure Multi-Factor Authentication
Server firewall requirements.

Upcoming changes to user experience in Identity Secure Score

Type: Plan for change
Ser vice categor y: Identity Protection Product capability: Identity Security & Protection
We're updating the Identity Secure Score portal to align with the changes introduced in Microsoft Secure Score’s
new release.
The preview version with the changes will be available at the beginning of September. The changes in the preview
version include:
“Identity Secure Score” renamed to “Secure Score for Identity” for brand alignment with Microsoft Secure Score
Points normalized to standard scale and reported in percentages instead of points
In this preview, customers can toggle between the existing experience and the new experience. This preview will last
until the end of November 2020. After the preview, the customers will automatically be directed to the new UX
experience.

New Restricted Guest Access Permissions in Azure AD - Public Preview

Type: New feature
Ser vice categor y: Access Control
Product capability: User Management
We've updated directory level permissions for guest users. These permissions allow administrators to require
additional restrictions and controls on external guest user access. Admins can now add additional restrictions for
external guests' access to user and groups' profile and membership information. With this public preview feature,
customers can manage external user access at scale by obfuscating group memberships, including restricting guest
users from seeing memberships of the group(s) they are in.
To learn more, see Restricted Guest Access Permissions and Users Default Permissions.

General availability of delta queries for service principals

Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
Microsoft Graph Delta Query now supports the resource type in v1.0:
Service Principal
Now clients can track changes to those resources efficiently and provides the best solution to synchronize changes
to those resources with a local data store. To learn how to configure these resources in a query, see Use delta query
to track changes in Microsoft Graph data.

General availability of delta queries for oAuth2PermissionGrant

Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
Microsoft Graph Delta Query now supports the resource type in v1.0:
OAuth2PermissionGrant
Clients can now track changes to those resources efficiently and provides the best solution to synchronize changes
to those resources with a local data store. To learn how to configure these resources in a query, see Use delta query
to track changes in Microsoft Graph data.

New Federated Apps available in Azure AD Application gallery - August 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In August 2020 we have added following 25 new applications in our App gallery with Federation support:
Backup365, Soapbox, Alma SIS, Enlyft Dynamics 365 Connector, Serraview Space Utilization Software Solutions,
Uniq, Visibly, Zylo, Edmentum - Courseware Assessments Exact Path, CyberLAB, Altamira HRM, WireWheel, Zix
Compliance and Capture, Greenlight Enterprise Business Controls Platform, Genetec Clearance, iSAMS, VeraSMART,
Amiko, Twingate, Funnel Leasing, Scalefusion, Bpanda, Vivun Calendar Connect, FortiGate SSL VPN, Wandera End
User
You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial
For listing your application in the Azure AD app gallery, read the details here https://aka.ms/AzureADAppRequest

Resource Forests now available for Azure AD DS

Type: New feature Ser vice categor y: Azure AD Domain Services
Product capability: Azure AD Domain Services
The capability of resource forests in Azure AD Domain Services is now generally available. You can now enable
authorization without password hash synchronization to use Azure AD Domain Services, including smart-card
authorization. To learn more, see Replica sets concepts and features for Azure Active Directory Domain Services
(preview).

Regional replica support for Azure AD DS managed domains now available

Type: New feature
Ser vice categor y: Azure AD Domain Services
Product capability: Azure AD Domain Services
You can expand a managed domain to have more than one replica set per Azure AD tenant. Replica sets can be
added to any peered virtual network in any Azure region that supports Azure AD Domain Services. Additional
replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure
region goes offline. To learn more, see Replica sets concepts and features for Azure Active Directory Domain
Services (preview).

General Availability of Azure AD My Sign-Ins

Type: New feature
Ser vice categor y: Authentications (Logins)
Product capability: End User Experiences
Azure AD My Sign-Ins is a new feature that allows enterprise users to review their sign-in history to check for any
unusual activity. Additionally, this feature allows end-users to report “This wasn’t me” or “This was me” on
suspicious activities. To learn more about using this feature, see View and search your recent sign-in activity from
the My Sign-Ins page.

SAP SuccessFactors HR driven user provisioning to Azure AD is now generally available

Type: New feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
You can now integrate SAP SuccessFactors as the authoritative identity source with Azure AD and automate the
end-to-end identity lifecycle using HR events like new hires and terminations to drive provisioning and de-
provisioning of accounts in Azure AD.
To learn more about how to configure SAP SuccessFactors inbound provisioning to Azure AD, refer to the tutorial
Configure SAP SuccessFactors to Active Directory user provisioning.

Custom Open ID Connect MS Graph API support for Azure AD B2C

Type: New feature
Ser vice categor y: B2C - Consumer Identity Management
Product capability: B2B/B2C
Previously, Custom Open ID Connect providers could only be added or managed through the Azure portal. Now
the Azure AD B2C customers can add and manage them through Microsoft Graph APIs beta version as well. To
learn how to configure this resource with APIs, see identityProvider resource type.

Assign Azure AD built-in roles to cloud groups

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
You can now assign Azure AD built-in roles to cloud groups with this new feature. For example, you can assign the
SharePoint Administrator role to Contoso_SharePoint_Admins group. You can also use PIM to make the group an
eligible member of the role, instead of granting standing access. To learn how to configure this feature, see Use
cloud groups to manage role assignments in Azure Active Directory (preview).

Insights Business Leader built-in role now available

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Users in the Insights Business Leader role can access a set of dashboards and insights via the M365 Insights
application. This includes full access to all dashboards and presented insights and data exploration functionality.
However, users in this role don't have access to product configuration settings, which is the responsibility of the
Insights Administrator role. To learn more about this role, see Administrator role permissions in Azure Active
Directory

Insights Administrator built-in role now available

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Users in the Insights Administrator role can access the full set of administrative capabilities in the M365 Insights
application. A user in this role can read directory information, monitor service health, file support tickets, and
access the Insights administrator settings aspects. To learn more about this role, see Administrator role permissions
in Azure Active Directory

Application Admin and Cloud Application Admin can manage extension properties of applications
Type: Changed feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Previously, only the Global Administrator could manage the extension property. We're now enabling this capability
for the Application Administrator and Cloud Application Administrator as well.

MIM 2016 SP2 hotfix 4.6.263.0 and connectors 1.1.1301.0

Type: Changed feature
Ser vice categor y: Microsoft Identity Manager
Product capability: Identity Lifecycle Management
A hotfix rollup package (build 4.6.263.0) is available for Microsoft Identity Manager (MIM) 2016 Service Pack 2
(SP2). This rollup package contains updates for the MIM CM, MIM Synchronization Manager, and PAM components.
In addition, the MIM generic connectors build 1.1.1301.0 includes updates for the Graph connector.

July 2020
As an IT Admin, I want to target client apps using Conditional Access
Type: Plan for change
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
With the GA release of the client apps condition in Conditional Access, new policies will now apply by default to all
client applications. This includes legacy authentication clients. Existing policies will remain unchanged, but the
Configure Yes/No toggle will be removed from existing policies to easily see which client apps are applied to by the
policy.
When creating a new policy, make sure to exclude users and service accounts that are still using legacy
authentication; if you don't, they will be blocked. Learn more.

Upcoming SCIM compliance fixes

Type: Plan for change
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
The Azure AD provisioning service leverages the SCIM standard for integrating with applications. Our
implementation of the SCIM standard is evolving, and we expect to make changes to our behavior around how we
perform PATCH operations as well as set the property "active" on a resource. Learn more.

Group owner setting on Azure Admin portal will be changed

Type: Plan for change
Ser vice categor y: Group Management
Product capability: Collaboration
Owner settings on Groups general setting page can be configured to restrict owner assignment privileges to a
limited group of users in the Azure Admin portal and Access Panel. We will soon have the ability to assign group
owner privilege not only on these two UX portals but also enforce the policy on the backend to provide consistent
behavior across endpoints, such as PowerShell and Microsoft Graph.
We will start to disable the current setting for the customers who are not using it and will offer an option to scope
users for group owner privilege in the next few months. For guidance on updating group settings, see Edit your
group information using Azure Active Directory.

Azure Active Directory Registration Service is ending support for TLS 1.0 and 1.1
Type: Plan for change
Ser vice categor y: Device Registration and Management
Product capability: Platform
Transport layer security (TLS) 1.2 and update servers and clients will soon communicate with Azure Active
Directory Device Registration Service. Support for TLS 1.0 and 1.1 for communication with Azure AD Device
Registration service will retire:
On August 31, 2020, in all sovereign clouds (GCC High, DoD, etc.)
On October 30, 2020, in all commercial clouds
Learn more about TLS 1.2 for the Azure AD Registration Service.

Windows Hello for Business Sign Ins visible in Azure AD Sign In Logs
Type: Fixed
Ser vice categor y: Reporting
Product capability: Monitoring & Reporting
Windows Hello for Business allows end-users to sign into Windows machines with a gesture (such as a PIN or
biometric). Azure AD admins may want to differentiate Windows Hello for Business sign-ins from other Windows
sign-ins as part of an organization's journey to passwordless authentication.
Admins can now see whether a Windows authentication used Windows Hello for Business by checking the
Authentication Details tab for a Windows sign-in event in the Azure AD Sign-Ins blade in the Azure Portal. Windows
Hello for Business authentications will include "WindowsHelloForBusiness" in the Authentication Method field. For
more information on interpreting Sign-In Logs, please see the Sign-In Logs documentation.

Fixes to group deletion behavior and performance improvements

Type: Fixed
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
Previously, when a group changed from "in-scope" to "out-of-scope" and an admin clicked restart before the
change was completed, the group object was not being deleted. Now the group object will be deleted from the
target application when it goes out of scope (disabled, deleted, unassigned, or did not pass scoping filter). Learn
more.

Public Preview: Admins can now add custom content in the email to reviewers when creating an access review
Type: New feature
Ser vice categor y: Access Reviews
Product capability: Identity Governance
When a new access review is created, the reviewer receives an email requesting them to complete the access
review. Many of our customers asked for the ability to add custom content to the email, such as contact
information, or other additional supporting content to guide the reviewer.
Now available in public preview, administrators can specify custom content in the email sent to reviewers by
adding content in the "advanced" section of Azure AD Access Reviews. For guidance on creating access reviews, see
Create an access review of groups and applications in Azure AD access reviews.

Authorization Code Flow for Single -page apps available

Type: New feature
Ser vice categor y: Authentications (Logins)
Product capability: Developer Experience
Because of modern browser 3rd party cookie restrictions such as Safari ITP, SPAs will have to use the authorization
code flow rather than the implicit flow to maintain SSO, and MSAL.js v 2.x will now support the authorization code
flow.
There are corresponding updates to the Azure portal so you can update your SPA to be type "spa" and use the auth
code flow. See Sign in users and get an access token in a JavaScript SPA using the auth code flow for further
guidance.

Azure AD Application Proxy now supports the Remote Desktop Services Web Client
Type: New feature
Ser vice categor y: App Proxy
Product capability: Access Control
Azure AD Application Proxy now supports the Remote Desktop Services (RDS) Web Client. The RDS web client
allows users to access Remote Desktop infrastructure through any HTLM5-capable browser such as Microsoft Edge,
Internet Explorer 11, Google Chrome, etc. Users can interact with remote apps or desktops like they would with a
local device from anywhere. By using Azure AD Application Proxy you can increase the security of your RDS
deployment by enforcing pre-authentication and Conditional Access policies for all types of rich client apps. For
guidance, see Publish Remote Desktop with Azure AD Application Proxy.

Next generation Azure AD B2C user flows in public preview

Type: New feature
Ser vice categor y: B2C - Consumer Identity Management
Product capability: B2B/B2C
Simplified user flow experience offers feature parity with preview features and is the home for all new features.
Users will be able to enable new features within the same user flow, reducing the need to create multiple versions
with every new feature release. Lastly, the new, user-friendly UX simplifies the selection and creation of user flows.
Try it now by creating a user flow.
For more information about users flows, see [User flow versions in Azure Active Directory B2C](../../active-
directory-b2c/user-flow-versions.md#:~:text= User flow ,account. Usi ... 1 more rows ).

New Federated Apps available in Azure AD Application gallery - July 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In July 2020 we have added following 55 new applications in our App gallery with Federation support:
Clap Your Hands, Appreiz, Inextor Vault, Beekast, Templafy OpenID Connect, PeterConnects receptionist, AlohaCloud,
Control Tower, Cocoom, COINS Construction Cloud, Medxnote MT, Reflekt, Rever, MyCompanyArchive,
GReminders, Titanfile, Wootric, SolarWinds Orion, OpenText Directory Services, Datasite, BlogIn, IntSights, kpifire,
Textline, Cloud Academy - SSO, Community Spark, Chatwork, CloudSign, C3M Cloud Control, SmartHR,
NumlyEngage™, Michigan Data Hub Single Sign-On, Egress, SendSafely, Eletive, Right-Hand Cybersecurity ADI,
Fyde Enterprise Authentication, Verme, Lenses.io, Momenta, Uprise, Q, CloudCords, TellMe Bot, Inspire, Maverics
Identity Orchestrator SAML Connector, Smartschool (School Management System), Zepto - Intelligent timekeeping,
Studi.ly, Trackplan, Skedda, WhosOnLocation, Coggle, Kemp LoadMaster, BrowserStack Single Sign-on
You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial
For listing your application in the Azure AD app gallery, please read the details here
https://aka.ms/AzureADAppRequest

New provisioning connectors in the Azure AD Application Gallery - July 2020

Type: New feature
Ser vice categor y: App Provisioning
Product capability: 3rd Party Integration
You can now automate creating, updating, and deleting user accounts for the newly integrated app LinkedIn
Learning.
For more information about how to better secure your organization by using automated user account provisioning,
see Automate user provisioning to SaaS applications with Azure AD.

View role assignments across all scopes and ability to download them to a csv file
Type: Changed feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
You can now view role assignments across all scopes for a role in the "Roles and administrators" tab in the Azure
AD portal. You can also download those role assignments for each role into a CSV file. For guidance on viewing and
adding role assignments, see View and assign administrator roles in Azure Active Directory.

Azure Multi-Factor Authentication Software Development (Azure MFA SDK ) Deprecation

Type: Deprecated
Ser vice categor y: MFA
Product capability: Identity Security & Protection
The Azure Multi-Factor Authentication Software Development (Azure MFA SDK) reached the end of life on
November 14th, 2018, as first announced in November 2017. Microsoft will be shutting down the SDK service
effective on September 30th, 2020. Any calls made to the SDK will fail.
If your organization is using the Azure MFA SDK, you need to migrate by September 30th, 2020:
Azure MFA SDK for MIM: If you use the SDK with MIM, you should migrate to Azure MFA Server and activate
Privileged Access Management (PAM) following these instructions.
Azure MFA SDK for customized apps: Consider integrating your app into Azure AD and use Conditional Access
to enforce MFA. To get started, review this page.

June 2020
User risk condition in Conditional Access policy
Type: Plan for change
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
User risk support in Azure AD Conditional Access policy allows you to create multiple user risk-based policies.
Different minimum user risk levels can be required for different users and apps. Based on user risk, you can create
policies to block access, require multi-factor authentication, secure password change, or redirect to Microsoft Cloud
App Security to enforce session policy, such as additional auditing.
The user risk condition requires Azure AD Premium P2 because it uses Azure Identity Protection, which is a P2
offering. for more information about conditional access, refer to Azure AD Conditional Access documentation.

SAML SSO now supports apps that require SPNameQualifier to be set when requested
Type: Fixed
Ser vice categor y: Enterprise Apps
Product capability: SSO
Some SAML applications require SPNameQualifier to be returned in the assertion subject when requested. Now
Azure AD responds correctly when a SPNameQualifier is requested in the request NameID policy. This also works
for SP initiated sign-in, and IdP initiated sign-in will follow. To learn more about SAML protocol in Azure Active
Directory, see Single Sign-On SAML protocol.

Azure AD B2B Collaboration supports inviting MSA and Google users in Azure Government tenants
Type: New feature
Ser vice categor y: B2B
Product capability: B2B/B2C
Azure Government tenants using the B2B collaboration features can now invite users that have a Microsoft or
Google account. To find out if your tenant can use these capabilities, follow the instructions at How can I tell if B2B
collaboration is available in my Azure US Government tenant?

User object in MS Graph v1 now includes externalUserState and externalUserStateChangedDateTime properties

Type: New feature
Ser vice categor y: B2B
Product capability: B2B/B2C
The externalUserState and externalUserStateChangedDateTime properties can be used to find invited B2B guests
who have not accepted their invitations yet as well as build automation such as deleting users who haven't
accepted their invitations after some number of days. These properties are now available in MS Graph v1. For
guidance on using these properties, refer to User resource type.

Manage authentication sessions in Azure AD Conditional Access is now generally available

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
Authentication session management capabilities allow you to configure how often your users need to provide sign-
in credentials and whether they need to provide credentials after closing and reopening browsers to offer more
security and flexibility in your environment.
Additionally, authentication session management used to only apply to the First Factor Authentication on Azure AD
joined, Hybrid Azure AD joined, and Azure AD registered devices. Now authentication session management will
apply to MFA as well. For more information, see Configure authentication session management with Conditional
Access.

New Federated Apps available in Azure AD Application gallery - June 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In June 2020 we have added the following 29 new applications in our App gallery with Federation support:
Shopify Plus, Ekarda, MailGates, BullseyeTDP, Raketa, Segment, Ai Auditor, Pobuca Connect, Proto.io, Gatekeeper,
Hub Planner, Ansira-Partner Go-to-Market Toolbox, IBM Digital Business Automation on Cloud, Kisi Physical
Security, ViewpointOne, IntelligenceBank, pymetrics, Zero, InStation, edX for Business SAML 2.0 Integration, MOOC
Office 365, SmartKargo, PKIsigning platform, SiteIntel, Field iD, Curricula SAML, Perforce Helix Core - Helix
Authentication Service, MyCompliance Cloud, Smallstep SSH
You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial. For listing your
application in the Azure AD app gallery, please read the details here: https://aka.ms/AzureADAppRequest.

API connectors for External Identities self-service sign-up are now in public preview
Type: New feature
Ser vice categor y: B2B
Product capability: B2B/B2C
External Identities API connectors enable you to leverage web APIs to integrate self-service sign-up with external
cloud systems. This means you can now invoke web APIs as specific steps in a sign-up flow to trigger cloud-based
custom workflows. For example, you can use API connectors to:
Integrate with a custom approval workflows.
Perform identity proofing
Validate user input data
Overwrite user attributes
Run custom business logic
For more information about all of the experiences possible with API connectors, see Use API connectors to
customize and extend self-service sign-up, or Customize External Identities self-service sign-up with web API
integrations.
Provision on-demand and get users into your apps in seconds
Type: New feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
The Azure AD provisioning service currently operates on a cyclic basis. The service runs every 40 mins. The on-
demand provisioning capability allows you to pick a user and provision them in seconds. This capability allows you
to quickly troubleshoot provisioning issues, without having to do a restart to force the provisioning cycle to start
again.

New permission for using Azure AD entitlement management in Graph

Type: New feature
Ser vice categor y: Other
Product capability: Entitlement Management
A new delegated permission EntitlementManagement.Read.All is now available for use with the Entitlement
Management API in Microsoft Graph beta. To find out more about the available APIs, see Working with the Azure
AD entitlement management API.

Identity Protection APIs available in v1.0

Type: New feature
Ser vice categor y: Identity Protection
Product capability: Identity Security & Protection
The riskyUsers and riskDetections Microsoft Graph APIs are now generally available. Now that they are available at
the v1.0 endpoint, we invite you to use them in production. For more information, please check out the Microsoft
Graph docs.

Sensitivity labels to apply policies to Microsoft 365 groups is now generally available
Type: New feature
Ser vice categor y: Group Management
Product capability: Collaboration
You can now create sensitivity labels and use the label settings to apply policies to Microsoft 365 groups, including
privacy (Public or Private) and external user access policy. You can create a label with the privacy policy to be
Private, and external user access policy to not allow to add guest users. When a user applies this label to a group,
the group will be private, and no guest users are allowed to be added to the group.
Sensitivity labels are important to protect your business-critical data and enable you to manage groups at scale, in
a compliant and secure fashion. For guidance on using sensitivity labels, refer to Assign sensitivity labels to Office
365 groups in Azure Active Directory (preview).

Updates to support for Microsoft Identity Manager for Azure AD Premium customers
Type: Changed feature
Ser vice categor y: Microsoft Identity Manager
Product capability: Identity Lifecycle Management
Azure Support is now available for Azure AD integration components of Microsoft Identity Manager 2016, through
the end of Extended Support for Microsoft Identity Manager 2016. Read more at Support update for Azure AD
Premium customers using Microsoft Identity Manager.

The use of group membership conditions in SSO claims configuration is increased

Type: Changed feature
Ser vice categor y: Enterprise Apps
Product capability: SSO
Previously, the number of groups you could use when you conditionally change claims based on group
membership within any single application configuration was limited to 10. The use of group membership
conditions in SSO claims configuration has now increased to a maximum of 50 groups. For more information on
how to configure claims, refer to Enterprise Applications SSO claims configuration.

Enabling basic formatting on the Sign In Page Text component in Company Branding.
Type: Changed feature
Ser vice categor y: Authentications (Logins)
Product capability: User Authentication
The Company Branding functionality on the Azure AD/Microsoft 365 login experience has been updated to allow
the customer to add hyperlinks and simple formatting, including bold font, underline, and italics. For guidance on
using this functionality, see Add branding to your organization's Azure Active Directory sign-in page.

Provisioning performance improvements

Type: Changed feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
The provisioning service has been updated to reduce the time for an incremental cycle to complete. This means that
users and groups will be provisioned into their applications faster than they were previously. All new provisioning
jobs created after 6/10/2020 will automatically benefit from the performance improvements. Any applications
configured for provisioning before 6/10/2020 will need to restart once after 6/10/2020 to take advantage of the
performance improvements.

Announcing the deprecation of ADAL and MS Graph Parity

Type: Deprecated
Ser vice categor y: N/A
Product capability: Device Lifecycle Management
Now that Microsoft Authentication Libraries (MSAL) is available, we will no longer add new features to the Azure
Active Directory Authentication Libraries (ADAL) and will end security patches on June 30th, 2022. For more
information on how to migrate to MSAL, refer to Migrate applications to Microsoft Authentication Library (MSAL).
Additionally, we have finished the work to make all Azure AD Graph functionality available through MS Graph. So,
Azure AD Graph APIs will receive only bugfix and security fixes through June 30th, 2022. For more information, see
Update your applications to use Microsoft Authentication Library and Microsoft Graph API

May 2020
Retirement of properties in signIns, riskyUsers, and riskDetections APIs
Type: Plan for change
Ser vice categor y: Identity Protection
Product capability: Identity Security & Protection
Currently, enumerated types are used to represent the riskType property in both the riskDetections API and
riskyUserHistoryItem (in preview). Enumerated types are also used for the riskEventTypes property in the signIns
API. Going forward we will represent these properties as strings.
Customers should transition to the riskEventType property in the beta riskDetections and riskyUserHistoryItem API,
and to riskEventTypes_v2 property in the beta signIns API by September 9th, 2020. At that date, we will be retiring
the current riskType and riskEventTypes properties. For more information, refer to Changes to risk event properties
and Identity Protection APIs on Microsoft Graph.

Deprecation of riskEventTypes property in signIns v1.0 API on Microsoft Graph

Type: Plan for change
Ser vice categor y: Reporting
Product capability: Identity Security & Protection
Enumerated types will switch to string types when representing risk event properties in Microsoft Graph
September 2020. In addition to impacting the preview APIs, this change will also impact the in-production signIns
API.
We have introduced a new riskEventsTypes_v2 (string) property to the signIns v1.0 API. We will retire the current
riskEventTypes (enum) property on June 11, 2022 in accordance with our Microsoft Graph deprecation policy.
Customers should transition to the riskEventTypes_v2 property in the v1.0 signIns API by June 11, 2022. For more
information, refer to Deprecation of riskEventTypes property in signIns v1.0 API on Microsoft Graph.

Upcoming changes to MFA email notifications

Type: Plan for change
Ser vice categor y: MFA
Product capability: Identity Security & Protection
We are making the following changes to the email notifications for cloud MFA:
E-mail notifications will be sent from the following address: [email protected] and
[email protected]. We're updating the content of fraud alert emails to better indicate the
required steps to unblock uses.

New self-service sign up for users in federated domains who can't access Microsoft Teams because they aren't
synced to Azure Active Directory.
Type: Plan for change
Ser vice categor y: Authentications (Logins)
Product capability: User Authentication
Currently, users who are in domains federated in Azure AD, but who are not synced into the tenant, can't access
Teams. Starting at the end of June, this new capability will enable them to do so by extending the existing email
verified sign up feature. This will allow users who can sign in to a federated IdP, but who don't yet have a user object
in Azure ID, to have a user object created automatically and be authenticated for Teams. Their user object will be
marked as "self-service sign up." This is an extension of the existing capability to do email verified self-sign up that
users in managed domains can do and can be controlled using the same flag. This change will complete rolling out
during the following two months. Watch for documentation updates here.

Upcoming fix: The OIDC discovery document for the Azure Government cloud is being updated to reference
the correct Graph endpoints.
Type: Plan for change
Ser vice categor y: Sovereign Clouds
Product capability: User Authentication
Starting in June, the OIDC discovery document Microsoft identity platform and OpenID Connect protocol on the
Azure Government cloud endpoint (login.microsoftonline.us), will begin to return the correct National cloud graph
endpoint (https://graph.microsoft.us or https://dod-graph.microsoft.us), based on the tenant provided. It currently
provides the incorrect Graph endpoint (graph.microsoft.com) "msgraph_host" field.
This bug fix will be rolled out gradually over approximately 2 months.

Azure Government users will no longer be able to sign in on login.microsoftonline.com

Type: Plan for Change
Ser vice categor y: Sovereign Clouds
Product capability: User Authentication
On 1 June 2018, the official Azure Active Directory (AAD) Authority for Azure Government changed from
https://login-us.microsoftonline.com to https://login.microsoftonline.us. If you own an application within an Azure
Government tenant, you must update your application to sign users in on the .us endpoint.
Starting May 5th, Azure AD will begin enforcing the endpoint change, blocking Azure Government users from
signing into apps hosted in Azure Government tenants using the public endpoint (microsoftonline.com). Impacted
apps will begin seeing an error AADSTS900439 - USGClientNotSupportedOnPublicEndpoint.
There will be a gradual rollout of this change with enforcement expected to be complete across all apps June 2020.
For more details, please see the Azure Government blog post.

SAML Single Logout request now sends NameID in the correct format
Type: Fixed
Ser vice categor y: Authentications (Logins)
Product capability: User Authentication
When a user clicks on sign-out (e.g., in the MyApps portal), Azure AD sends a SAML Single Logout message to each
app that is active in the user session and has a Logout URL configured. These messages contain a NameID in a
persistent format.
If the original SAML sign-in token used a different format for NameID (e.g. email/UPN), then the SAML app cannot
correlate the NameID in the logout message to an existing session (as the NameIDs used in both messages are
different), which caused the logout message to be discarded by the SAML app and the user to stay logged in. This
fix makes the sign-out message consistent with the NameID configured for the application.

Hybrid Identity Administrator role is now available with Cloud Provisioning

Type: New feature
Ser vice categor y: Azure AD Cloud Provisioning
Product capability: Identity Lifecycle Management
IT Admins can start using the new "Hybrid Admin" role as the least privileged role for setting up Azure ADConnect
Cloud Provisioning. With this new role, you no longer have to use the Global Admin role to setup and configure
Cloud Provisioning. Learn more.

New Federated Apps available in Azure AD Application gallery - May 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In May 2020, we have added the following 36 new applications in our App gallery with Federation support:
Moula, Surveypal, Kbot365, TackleBox, Powell Teams, Talentsoft Assistant, ASC Recording Insights, GO1, B-Engaged,
Competella Contact Center Workgroup, Asite, ImageSoft Identity, My IBISWorld, insuite, Change Process
Management, Cyara CX Assurance Platform, Smart Global Governance, Prezi, Mapbox, Datava Enterprise Service
Platform, Whimsical, Trelica, EasySSO for Confluence, EasySSO for BitBucket, EasySSO for Bamboo, Torii, Axiad
Cloud, Humanage, ColorTokens ZTNA, CCH Tagetik, ShareVault, Vyond, TextExpander, Anyone Home CRM,
askSpoke, ice Contact Center
You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial.
For listing your application in the Azure AD app gallery, please read the details here
https://aka.ms/AzureADAppRequest.

Report-only mode for Conditional Access is now generally available

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
Report-only mode for Azure AD Conditional Access lets you evaluate the result of a policy without enforcing access
controls. You can test report-only policies across your organization and understand their impact before enabling
them, making deployment safer and easier. Over the past few months, we’ve seen strong adoption of report-only
mode—over 26M users are already in scope of a report-only policy. With the announcement today, new Azure AD
Conditional Access policies will be created in report-only mode by default. This means you can monitor the impact
of your policies from the moment they’re created. And for those of you who use the MS Graph APIs, you can
manage report-only policies programmatically as well.

Self-service sign up for guest users

Type: New feature
Ser vice categor y: B2B
Product capability: B2B/B2C
With External Identities in Azure AD, you can allow people outside your organization to access your apps and
resources while letting them sign in using whatever identity they prefer. When sharing an application with external
users, you might not always know in advance who will need access to the application. With self-service sign-up, you
can enable guest users to sign up and gain a guest account for your line of business (LOB) apps. The sign-up flow
can be created and customized to support Azure AD and social identities. You can also collect additional
information about the user during sign-up.

Conditional Access Insights and Reporting workbook is generally available

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
The insights and reporting workbook gives admins a summary view of Azure AD Conditional Access in their tenant.
With the capability to select an individual policy, admins can better understand what each policy does and monitor
any changes in real-time. The workbook streams data stored in Azure Monitor, which you can set up in a few
minutes following these instructions. To make the dashboard more discoverable, we’ve moved it to the new
insights and reporting tab within the Azure AD Conditional Access menu.

Policy details blade for Conditional Access is in public preview

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
The new policy details blade displays the assignments, conditions, and controls satisfied during conditional access
policy evaluation. You can access the blade by selecting a row in the Conditional Access or Report-only tabs of the
Sign-in details.

New query capabilities for Directory Objects in Microsoft Graph are in Public Preview
Type: New feature
Ser vice categor y: MS Graph Product capability: Developer Experience
New capabilities are being introduced for Microsoft Graph Directory Objects APIs, enabling Count, Search, Filter,
and Sort operations. This will give developers the ability to quickly query our Directory Objects without
workarounds such as in-memory filtering and sorting. Find out more in this blog post.
We are currently in Public Preview, looking for feedback. Please send your comments with this brief survey.

Configure SAML -based single sign-on using Microsoft Graph API (Beta)
Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: SSO
Support for creating and configuring an application from the Azure AD Gallery using MS Graph APIs in Beta is now
available. If you need to set up SAML-based single sign-on for multiple instances of an application, save time by
using the Microsoft Graph APIs to automate the configuration of SAML-based single sign-on.

New provisioning connectors in the Azure AD Application Gallery - May 2020

Type: New feature
Ser vice categor y: App Provisioning
Product capability: 3rd Party Integration
You can now automate creating, updating, and deleting user accounts for these newly integrated apps:
8x8
Juno Journey
MediusFlow
New Relic by Organization
Oracle Cloud Infrastructure Console
For more information about how to better secure your organization by using automated user account provisioning,
see Automate user provisioning to SaaS applications with Azure AD.

SAML Token Encryption is Generally Available

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: SSO
SAML token encryption allows applications to be configured to receive encrypted SAML assertions. The feature is
now generally available in all clouds.

Group name claims in application tokens is Generally Available

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: SSO
The group claims issued in a token can now be limited to just those groups assigned to the application. This is
especially important when users are members of large numbers of groups and there was a risk of exceeding token
size limits. With this new capability in place, the ability to add group names to tokens is generally available.

Workday Writeback now supports setting work phone number attributes

Type: New feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
We have enhanced the Workday Writeback provisioning app to now support writeback of work phone number and
mobile number attributes. In addition to email and username, you can now configure the Workday Writeback
provisioning app to flow phone number values from Azure AD to Workday. For more details on how to configure
phone number writeback, refer to the Workday Writeback app tutorial.

Publisher Verification (preview)

Type: New feature
Ser vice categor y: Other
Product capability: Developer Experience
Publisher verification (preview) helps admins and end-users understand the authenticity of application developers
integrating with the Microsoft identity platform. For details, refer to Publisher verification (preview).

Authorization Code Flow for Single -page apps

Type: Changed feature Ser vice categor y: Authentication Product capability: Developer Experience
Because of modern browser 3rd party cookie restrictions such as Safari ITP, SPAs will have to use the authorization
code flow rather than the implicit flow to maintain SSO; MSAL.js v 2.x will now support the authorization code flow.
There as corresponding updates to the Azure portal so you can update your SPA to be type "spa" and use the auth
code flow. For guidance, refer to Quickstart: Sign in users and get an access token in a JavaScript SPA using the auth
code flow.

Improved Filtering for Devices is in Public Preview

Type: Changed Feature
Ser vice categor y: Device Management Product capability: Device Lifecycle Management
Previously, the only filters you could use were "Enabled" and "Activity date." Now, you can filter your list of devices
on more properties, including OS type, join type, compliance, and more. These additions should simplify locating a
particular device.

The new App registrations experience for Azure AD B2C is now generally available
Type: Changed Feature
Ser vice categor y: B2C - Consumer Identity Management
Product capability: Identity Lifecycle Management
The new App registrations experience for Azure AD B2C is now generally available.
Previously, you had to manage your B2C consumer-facing applications separately from the rest of your apps using
the legacy 'Applications' experience. That meant different app creation experiences across different places in Azure.
The new experience shows all B2C app registrations and Azure AD app registrations in one place and provides a
consistent way to manage them. Whether you need to manage a customer-facing app or an app that has access to
Microsoft Graph to programmatically manage Azure AD B2C resources, you only need to learn one way to do
things.
You can reach the new experience by navigating the Azure AD B2C service and selecting the App registrations
blade. The experience is also accessible from the Azure Active Directory service.
The Azure AD B2C App registrations experience is based on the general App Registration experience for Azure AD
tenants but is tailored for Azure AD B2C. The legacy "Applications" experience will be deprecated in the future.
For more information, visit The New app registration experience for Azure AD B2C.
April 2020
Combined security info registration experience is now generally available
Type: New feature
Ser vice categor y: Authentications (Logins)
Product capability: Identity Security & Protection
The combined registration experience for Multi-Factor Authentication (MFA) and Self-Service Password Reset
(SSPR) is now generally available. This new registration experience enables users to register for MFA and SSPR in a
single, step-by-step process. When you deploy the new experience for your organization, users can register in less
time and with fewer hassles. Check out the blog post here.

Continuous Access Evaluation

Type: New feature
Ser vice categor y: Authentications (Logins)
Product capability: Identity Security & Protection
Continuous Access Evaluation is a new security feature that enables near real-time enforcement of policies on
relying parties consuming Azure AD Access Tokens when events happen in Azure AD (such as user account
deletion). We are rolling this feature out first for Teams and Outlook clients. For more details, please read our blog
and documentation.

SMS Sign-in: Firstline Workers can sign in to Azure AD-backed applications with their phone number and no
password
Type: New feature
Ser vice categor y: Authentications (Logins)
Product capability: User Authentication
Office is launching a series of mobile-first business apps that cater to non-traditional organizations, and to
employees in large organizations that don’t use email as their primary communication method. These apps target
frontline employees, deskless workers, field agents, or retail employees that may not get an email address from
their employer, have access to a computer, or to IT. This project will let these employees sign in to business
applications by entering a phone number and roundtripping a code. For more details, please see our admin
documentation and end user documentation.

Invite internal users to use B2B collaboration

Type: New feature
Ser vice categor y: B2B
Product capability:
We're expanding B2B invitation capability to allow existing internal accounts to be invited to use B2B collaboration
credentials going forward. This is done by passing the user object to the Invite API in addition to typical parameters
like the invited email address. The user's object ID, UPN, group membership, app assignment, etc. remain intact, but
going forward they'll use B2B to authenticate with their home tenant credentials rather than the internal credentials
they used before the invitation. For details, see the documentation.

Report-only mode for Conditional Access is now generally available

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
Report-only mode for Azure AD Conditional Access lets you evaluate the result of a policy without enforcing access
controls. You can test report-only policies across your organization and understand their impact before enabling
them, making deployment safer and easier. Over the past few months, we’ve seen strong adoption of report-only
mode, with over 26M users already in scope of a report-only policy. With this announcement, new Azure AD
Conditional Access policies will be created in report-only mode by default. This means you can monitor the impact
of your policies from the moment they’re created. And for those of you who use the MS Graph APIs, you can also
manage report-only policies programmatically.

Conditional Access insights and reporting workbook is generally available

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
The Conditional Access insights and reporting workbook gives admins a summary view of Azure AD Conditional
Access in their tenant. With the capability to select an individual policy, admins can better understand what each
policy does and monitor any changes in real time. The workbook streams data stored in Azure Monitor, which you
can set up in a few minutes following these instructions. To make the dashboard more discoverable, we’ve moved it
to the new insights and reporting tab within the Azure AD Conditional Access menu.

Policy details blade for Conditional Access is in public preview

Type: New feature
Ser vice categor y: Conditional Access
Product capability: Identity Security & Protection
The new policy details blade displays which assignments, conditions, and controls were satisfied during conditional
access policy evaluation. You can access the blade by selecting a row in the Conditional Access or Repor t-only
tabs of the Sign-in details.

New Federated Apps available in Azure AD App gallery - April 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In April 2020, we've added these 31 new apps with Federation support to the app gallery:
SincroPool Apps, SmartDB, Float, LMS365, IWT Procurement Suite, Lunni, EasySSO for Jira, Virtual Training
Academy, Meraki Dashboard, Office 365 Mover, Speaker Engage, Honestly, Ally, DutyFlow, AlertMedia, gr8 People,
Pendo, HighGround, Harmony, Timetabling Solutions, SynchroNet CLICK, empower, Fortes Change Cloud, Litmus,
GroupTalk, Frontify, MongoDB Cloud, TickitLMS Learn, COCO, Nitro Productivity Suite , Trend Micro Web
Security(TMWS)
For more information about the apps, see SaaS application integration with Azure Active Directory. For more
information about listing your application in the Azure AD app gallery, see List your application in the Azure Active
Directory application gallery.

Microsoft Graph delta query support for oAuth2PermissionGrant available for Public Preview
Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
Delta query for oAuth2PermissionGrant is available for public preview! You can now track changes without having
to continuously poll Microsoft Graph. Learn more.

Microsoft Graph delta query support for organizational contact generally available
Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
Delta query for organizational contacts is generally available! You can now track changes in production apps
without having to continuously poll Microsoft Graph. Replace any existing code that continuously polls orgContact
data by delta query to significantly improve performance. Learn more.

Microsoft Graph delta query support for application generally available

Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
Delta query for applications is generally available! You can now track changes in production apps without having to
continuously poll Microsoft Graph. Replace any existing code that continuously polls application data by delta
query to significantly improve performance. Learn more.

Microsoft Graph delta query support for administrative units available for Public Preview
Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience Delta query for administrative units is available for public preview! You
can now track changes without having to continuously poll Microsoft Graph. Learn more.

Manage authentication phone numbers and more in new Microsoft Graph beta APIs
Type: New feature
Ser vice categor y: MS Graph
Product capability: Developer Experience
These APIs are a key tool for managing your users’ authentication methods. Now you can programmatically pre-
register and manage the authenticators used for MFA and self-service password reset (SSPR). This has been one of
the most-requested features in the Azure MFA, SSPR, and Microsoft Graph spaces. The new APIs we’ve released in
this wave give you the ability to:
Read, add, update, and remove a user’s authentication phones
Reset a user’s password
Turn on and off SMS-sign-in
For more information, see Azure AD authentication methods API overview.
Administrative Units Public Preview
Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Administrative units allow you to grant admin permissions that are restricted to a department, region, or other
segment of your organization that you define. You can use administrative units to delegate permissions to regional
administrators or to set policy at a granular level. For example, a User account admin could update profile
information, reset passwords, and assign licenses for users only in their administrative unit.
Using administrative units, a central administrator could:
Create an administrative unit for decentralized management of resources
Assign a role with administrative permissions over only Azure AD users in an administrative unit
Populate the administrative units with users and groups as needed
For more information, see Administrative units management in Azure Active Directory (preview).

Printer Administrator and Printer Technician built-in roles

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Printer Administrator : Users with this rolecan register printers and manage all aspects of all printer
configurations in the Microsoft Universal Print solution, including the Universal Print Connector settings. They can
consent to all delegated print permission requests. Printer Administrators also have access to print reports.
Printer Technician : Users with this rolecan register printers and manage printer status in the Microsoft Universal
Print solution. They can also read all connector information. Key tasks a Printer Technician cannot do are set user
permissions on printers and sharing printers. Learn more.

Hybrid Identity Admin built-in role

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Users in this role can enable, configure and manage services and settings related to enabling hybrid identity in
Azure AD. This role grants the ability to configure Azure AD to one of the three supported authentication methods
—Password hash synchronization (PHS), Pass-through authentication (PTA) or Federation (AD FS or 3rd party
federation provider)—and to deploy related on-premises infrastructure to enable them. On-premises infrastructure
includes Provisioning and PTA agents. This role grants the ability to enable Seamless Single Sign-On (S-SSO) to
enable seamless authentication on non-Windows 10 devices or non-Windows Server 2016 computers. In addition,
this role grants the ability to see sign-in logs and to access health and analytics for monitoring and troubleshooting
purposes. Learn more.

Network Administrator built-in role

Type: New feature
Ser vice categor y: Azure AD roles
Product capability: Access Control
Users with this role can review network perimeter architecture recommendations from Microsoft that are based on
network telemetry from their user locations. Network performance for Office 365 relies on careful enterprise
customer network perimeter architecture, which is generally user location-specific. This role allows for editing of
discovered user locations and configuration of network parameters for those locations to facilitate improved
telemetry measurements and design recommendations. Learn more.

Bulk activity and downloads in the Azure AD admin portal experience

Type: New feature
Ser vice categor y: User Management
Product capability: Directory
Now you can perform bulk activities on users and groups in Azure AD by uploading a CSV file in the Azure AD
admin portal experience. You can create users, delete users, and invite guest users. And you can add and remove
members from a group.
You can also download lists of Azure AD resources from the Azure AD admin portal experience. You can download
the list of users in the directory, the list of groups in the directory, and the members of a particular group.
For more information, check out the following:
Create users or invite guest users
Delete users or restore deleted users
Download list of users or Download list of groups
Add (import) members or remove members or Download list of members for a group

My Staff delegated user management

Type: New feature
Ser vice categor y: User Management
Product capability:
My Staff enables Firstline Managers, such as a store manager, to ensure that their staff members are able to access
their Azure AD accounts. Instead of relying on a central helpdesk, organizations can delegate common tasks, such
as resetting passwords or changing phone numbers, to a Firstline Manager. With My Staff, a user who can’t access
their account can re-gain access in just a couple of clicks, with no helpdesk or IT staff required. For more
information, see the Manage your users with My Staff (preview) and Delegate user management with My Staff
(preview).

An upgraded end user experience in access reviews

Type: Changed feature
Ser vice categor y: Access Reviews
Product capability: Identity Governance
We have updated the reviewer experience for Azure AD access reviews in the My Apps portal. At the end of April,
your reviewers who are logged in to the Azure AD access reviews reviewer experience will see a banner that will
allow them to try the updated experience in My Access. Please note that the updated Access reviews experience
offers the same functionality as the current experience, but with an improved user interface on top of new
capabilities to enable your users to be productive. You can learn more about the updated experience here. This
public preview will last until the end of July 2020. At the end of July, reviewers who have not opted into the preview
experience will be automatically directed to My Access to perform access reviews. If you wish to have your
reviewers permanently switched over to the preview experience in My Access now, please make a request here.
Workday inbound user provisioning and writeback apps now support the latest versions of Workday Web
Services API
Type: Changed feature
Ser vice categor y: App Provisioning
Product capability:
Based on customer feedback, we have now updated the Workday inbound user provisioning and writeback apps in
the enterprise app gallery to support the latest versions of the Workday Web Services (WWS) API. With this
change, customers can specify the WWS API version that they would like to use in the connection string. This gives
customers the ability to retrieve more HR attributes available in the releases of Workday. The Workday Writeback
app now uses the recommended Change_Work_Contact_Info Workday web service to overcome the limitations of
Maintain_Contact_Info.
If no version is specified in the connection string, by default, the Workday inbound provisioning apps will continue
to use WWS v21.1 To switch to the latest Workday APIs for inbound user provisioning, customers need to update
the connection string as documented in the tutorial and also update the XPATHs used for Workday attributes as
documented in the Workday attribute reference guide.
To use the new API for writeback, there are no changes required in the Workday Writeback provisioning app. On
the Workday side, ensure that the Workday Integration System User (ISU) account has permissions to invoke the
Change_Work_Contact business process as documented in the tutorial section, Configure business process security
policy permissions.
We have updated our tutorial guide to reflect the new API version support.

Users with default access role are now in scope for provisioning
Type: Changed feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
Historically, users with the default access role have been out of scope for provisioning. We've heard feedback that
customers want users with this role to be in scope for provisioning. As of April 16, 2020, all new provisioning
configurations allow users with the default access role to be provisioned. Gradually we will change the behavior for
existing provisioning configurations to support provisioning users with this role. Learn more.

Updated provisioning UI
Type: Changed feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
We've refreshed our provisioning experience to create a more focused management view. When you navigate to
the provisioning blade for an enterprise application that has already been configured, you'll be able to easily
monitor the progress of provisioning and manage actions such as starting, stopping, and restarting provisioning.
Learn more.

Dynamic Group rule validation is now available for Public Preview

Type: Changed feature
Ser vice categor y: Group Management
Product capability: Collaboration
Azure Active Directory (Azure AD) now provides the means to validate dynamic group rules. On the Validate rules
tab, you can validate your dynamic rule against sample group members to confirm the rule is working as expected.
When creating or updating dynamic group rules, administrators want to know whether a user or a device will be a
member of the group. This helps evaluate whether a user or device meets the rule criteria and aids in
troubleshooting when membership is not expected.
For more information, see Validate a dynamic group membership rule (preview).

Identity Secure Score - Security Defaults and MFA improvement action updates
Type: Changed feature
Ser vice categor y: N/A
Product capability: Identity Security & Protection
Suppor ting security defaults for Azure AD improvement actions: Microsoft Secure Score will be updating
improvement actions to support security defaults in Azure AD, which make it easier to help protect your
organization with pre-configured security settings for common attacks. This will affect the following improvement
actions:
Ensure all users can complete multi-factor authentication for secure access
Require MFA for administrative roles
Enable policy to block legacy authentication
MFA improvement action updates: To reflect the need for businesses to ensure the upmost security while
applying policies that work with their business, Microsoft Secure Score has removed three improvement actions
centered around multi-factor authentication and added two.
Removed improvement actions:
Register all users for multi-factor authentication
Require MFA for all users
Require MFA for Azure AD privileged roles
Added improvement actions:
Ensure all users can complete multi-factor authentication for secure access
Require MFA for administrative roles
These new improvement actions require registering your users or admins for multi-factor authentication (MFA)
across your directory and establishing the right set of policies that fit your organizational needs. The main goal is to
have flexibility while ensuring all your users and admins can authenticate with multiple factors or risk-based
identity verification prompts. That can take the form of having multiple policies that apply scoped decisions, or
setting security defaults (as of March 16th) that let Microsoft decide when to challenge users for MFA. Read more
about what's new in Microsoft Secure Score.

March 2020
Unmanaged Azure Active Directory accounts in B2B update for March, 2021
Type: Plan for change
Ser vice categor y: B2B
Product capability: B2B/B2C
Beginning on March 31, 2021 , Microsoft will no longer support the redemption of invitations by creating
unmanaged Azure Active Directory (Azure AD) accounts and tenants for B2B collaboration scenarios. In preparation
for this, we encourage you to opt in to email one-time passcode authentication.

Users with the default access role will be in scope for provisioning
Type: Plan for change
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
Historically, users with the default access role have been out of scope for provisioning. We've heard feedback that
customers want users with this role to be in scope for provisioning. We're working on deploying a change so that
all new provisioning configurations will allow users with the default access role to be provisioned. Gradually, we'll
change the behavior for existing provisioning configurations to support provisioning users with this role. No
customer action is required. We'll post an update to our documentation once this change is in place.

Azure AD B2B collaboration will be available in Microsoft Azure operated by 21Vianet (Azure China 21Vianet)
tenants
Type: Plan for change
Ser vice categor y: B2B
Product capability: B2B/B2C
The Azure AD B2B collaboration capabilities will be made available in Microsoft Azure operated by 21Vianet (Azure
China 21Vianet) tenants, enabling users in an Azure China 21Vianet tenant to collaborate seamlessly with users in
other Azure China 21Vianet tenants. Learn more about Azure AD B2B collaboration.

Azure AD B2B Collaboration invitation email redesign

Type: Plan for change
Ser vice categor y: B2B
Product capability: B2B/B2C
The emails that are sent by the Azure AD B2B collaboration invitation service to invite users to the directory will be
redesigned to make the invitation information and the user's next steps clearer.

HomeRealmDiscovery policy changes will appear in the audit logs

Type: Fixed
Ser vice categor y: Audit
Product capability: Monitoring & Reporting
We fixed a bug where changes to the HomeRealmDiscovery policy were not included in the audit logs. You will now
be able to see when and how the policy was changed, and by whom.

New Federated Apps available in Azure AD App gallery - March 2020

Type: New feature
Ser vice categor y: Enterprise Apps
Product capability: 3rd Party Integration
In March 2020, we've added these 51 new apps with Federation support to the app gallery:
Cisco AnyConnect, Zoho One China, PlusPlus, Profit.co SAML App, iPoint Service Provider, contexxt.ai SPHERE,
Wisdom By Invictus, Flare Digital Signage, Logz.io - Cloud Observability for Engineers, SpectrumU, BizzContact,
Elqano SSO, MarketSignShare, CrossKnowledge Learning Suite, Netvision Compas, FCM HUB, RIB A/S Byggeweb
Mobile, GoLinks, Datadog, Zscaler B2B User Portal, LIFT, Planview Enterprise One, WatchTeams, Aster, Skills
Workflow, Node Insight, IP Platform, InVision, Pipedrive, Showcase Workshop, Greenlight Integration Platform,
Greenlight Compliant Access Management, Grok Learning, Miradore Online, Khoros Care, AskYourTeam,
TruNarrative, Smartwaiver, Bizagi Studio for Digital Process Automation, insuiteX, sybo, Britive, WhosOffice, E-days,
Kollective SDN, Witivio, Playvox, Korn Ferry 360, Campus Café, Catchpoint, Code42
For more information about the apps, see SaaS application integration with Azure Active Directory. For more
information about listing your application in the Azure AD app gallery, see List your application in the Azure Active
Directory application gallery.

Azure AD B2B Collaboration available in Azure Government tenants

Type: New feature
Ser vice categor y: B2B
Product capability: B2B/B2C
The Azure AD B2B collaboration features are now available between some Azure Government tenants. To find out if
your tenant is able to use these capabilities, follow the instructions at How can I tell if B2B collaboration is available
in my Azure US Government tenant?.

Azure Monitor integration for Azure Logs is now available in Azure Government
Type: New feature
Ser vice categor y: Reporting
Product capability: Monitoring & Reporting
Azure Monitor integration with Azure AD logs is now available in Azure Government. You can route Azure AD Logs
(Audit and Sign-in Logs) to a storage account, Event Hub and Log Analytics. Please check out the detailed
documentation as well as deployment plans for reporting and monitoring for Azure AD scenarios.

Identity Protection Refresh in Azure Government

Type: New feature
Ser vice categor y: Identity Protection
Product capability: Identity Security & Protection
We’re excited to share that we have now rolled out the refreshed Azure AD Identity Protectionexperience in the
Microsoft Azure Government portal. For more information, see our announcement blog post.

Disaster recovery: Download and store your provisioning configuration

Type: New feature
Ser vice categor y: App Provisioning
Product capability: Identity Lifecycle Management
The Azure AD provisioning service provides a rich set of configuration capabilities. Customers need to be able to
save their configuration so that they can refer to it later or roll back to a known good version. We've added the
ability to download your provisioning configuration as a JSON file and upload it when you need it. Learn more.

SSPR (self-service password reset) now requires two gates for admins in Microsoft Azure operated by 21Vianet
(Azure China 21Vianet)
Type: Changed feature
Ser vice categor y: Self-Service Password Reset
Product capability: Identity Security & Protection
Previously in Microsoft Azure operated by 21Vianet (Azure China 21Vianet), admins using self-service password
reset (SSPR) to reset their own passwords needed only one "gate" (challenge) to prove their identity. In public and
other national clouds, admins generally must use two gates to prove their identity when using SSPR. But because
we didn't support SMS or phone calls in Azure China 21Vianet, we allowed one-gate password reset by admins.
We're creating SSPR feature parity between Azure China 21Vianet and the public cloud. Going forward, admins
must use two gates when using SSPR. SMS, phone calls, and Authenticator app notifications and codes will be
supported. Learn more.

Password length is limited to 256 characters

Type: Changed feature
Ser vice categor y: Authentications (Logins)
Product capability: User Authentication
To ensure the reliability of the Azure AD service, user passwords are now limited in length to 256 characters. Users
with passwords longer than this will be asked to change their password on subsequent login, either by contacting
their admin or by using the self-service password reset feature.
This change was enabled on March 13th, 2020, at 10AM PST (18:00 UTC), and the error is AADSTS 50052,
InvalidPasswordExceedsMaxLength. See the breaking change notice for more details.

Azure AD sign-in logs are now available for all free tenants through the Azure portal
Type: Changed feature
Ser vice categor y: Reporting
Product capability: Monitoring & Reporting
Starting now, customers who have free tenants can access the Azure AD sign-in logs from the Azure portal for up
to 7 days. Previously, sign-in logs were available only for customers with Azure Active Directory Premium licenses.
With this change, all tenants can access these logs through the portal.

NOTE
Customers still need a premium license (Azure Active Directory Premium P1 or P2) to access the sign-in logs through
Microsoft Graph API and Azure Monitor.

Deprecation of Directory-wide groups option from Groups General Settings on Azure portal
Type: Deprecated
Ser vice categor y: Group Management
Product capability: Collaboration
To provide a more flexible way for customers to create directory-wide groups that best meet their needs, we've
replaced the Director y-wide Groups option from the Groups > General settings in the Azure portal with a link
to dynamic group documentation. We've improved our documentation to include more instructions so
administrators can create all-user groups that include or exclude guest users.