Azure AD and Microsoft Passport for Work in Windows 10

One of the benefits of Windows 10 devices that are registered with Azure AD is the convenience and security that comes with Windows Hello and Microsoft Passport for Work. In this post I’ll delve into the technology of Microsoft Passport for Work with Azure AD and how it relates to devices and strong user authentication.

Microsoft Passport for Work is supported on all three types of devices registered with Azure AD to authenticate to work apps. In this post I will focus primarily on Azure AD joined and domain joined devices.

Quick note on personal devices

For Windows personal devices running the November 2015 update, Microsoft Passport for Work is limited to protecting certificates for traditional apps (like VPN) with the associated user’s gesture that unlocks the credential (read further in this post for details). These certificates are deployed typically by the Mobile Device Management (MDM) system.

The Microsoft Passport for Work provisioning experience won’t show up during Add Work or School Account unless an MDM has been configured in Azure AD for auto-enrollment. In this case, a user working on the device won’t authenticate to Azure AD using the Microsoft Passport for Work credential. A future update of Windows will have this support.

On the other hand, the credential in a Windows 10 device (including personal devices), can be used to remotely authenticate to an Azure AD joined or domain joined device. For more information please look for a future post about Microsoft Passport for Work 2Go: using your phone to authenticate to Windows.


Passwords today

There is a problem today with passwords. They are easy to clone and easy to steal. Issues in their implementation make them insecure, and users have a hard time balancing convenience and security. Users typically find “workarounds” to make their life easier when facing security requirements (e.g. a complex password may end up being written in some unsecure location).

Microsoft Passport for Work replaces user passwords with strong device-bound user credentials protected by a user’s gesture (a PIN or a biometric gesture like fingerprint or facial recognition i.e. Windows Hello).

For more details on the problems of passwords please see Problems with traditional credentials section in the Microsoft Passport guide we recently published in TechNet.


The Microsoft Passport for Work credential

The credential is an asymmetric key (private-public key pair) with their private key stored securely in the device in the Trusted Platform Module (TPM), and its corresponding public key securely registered with Azure AD. In the absence of a TPM the keys are software generated and stored encrypted.

The private key does not leave its secure location (if TPM available), it is not known to Azure AD or AD and it never goes into the network. It is only accessible by a gesture that the user knows (a PIN) or the user “is” (bio-gesture) which protects the key cryptographically by encrypting it using a “Hello”. A Hello is an authenticator which is unique to the gesture, the device and the user.

The public key is registered securely with Azure AD after both the device and the user have authenticated. The user must strongly authenticate by providing a second factor of authentication. This is important because the Microsoft Passport for Work credential is considered a strong credential when authenticating to Azure AD. The credential meets multi-factor authentication (MFA) policy and tokens obtained with this credential will have a corresponding related claim.

Once the credential is provisioned, it is used for authentication to Azure AD.


Provisioning the Microsoft Passport for Work credential

All starts with a device becoming registered with Azure AD. A device needs to be Azure AD joined, domain joined (which has auto-registered with Azure AD) or configured with Add Work or School Account before holding a Microsoft Passport for Work credential.

After an Azure AD joined or domain joined device has completed registration, on the next user sign-in to Windows the Microsoft Passport for Work provisioning experience will show up. Registration of the public key with Azure AD happens through the Azure Device Registration Service (Azure DRS).

This experience is a web driven experience rendered in the Cloud eXperience Host (CXH), a special host with access to particular WinRT APIs in the system. This is the same host that is used to render the experience for Azure AD Join.

The experience is launched after the user signs in to Windows if the following conditions are true:

  1. Microsoft Passport for Work policy signals provisioning. This means either of the following conditions:
    • The device is Azure AD joined and Microsoft Passport for Work policy is not disabled (read it: in the absence of the policy being set the default behavior is to provision the credential).
    • The device is domain joined and policy is enabled (read it: in the absence of the policy being set the default behavior is to NOT provision the credential). This is because there is preparation needed in the on-premises infrastructure for a domain joined device to be able to authenticate to a domain controller (DC) using the credential. After the required setup is made, the org. can enable the policy. I’ll mention some considerations about supporting AD on-premises authentication later in the post.
  2. The current session is not a remote session. Note that this doesn’t mean that Microsoft Passport Provisioning for Work won’t happen on virtual machines (VMs), but just that the provisioning experience won’t show up if the user is connected to the VM or physical device via a Remote Desktop Services (RDS) session (which includes connecting to the computer using Hyper-V Enhanced Session Mode, so you know in case you want to try this in your lab on a Hyper-V host).

Once the conditions listed above are met the user will see the provisioning experience. The experience is hosted in the following location:

The user will see the following page:

Blog - Set up a PIN

Once the user clicks on the ‘Create PIN’ button a WinRT API part of dsreg.dll is called. This registration API performs two operations: 1) authenticates the current user to get a token to Azure DRS, and 2) generates the key pair and registers the public key with Azure DRS using the token obtained in (1).


(1) Authentication of user to Azure DRS

The registration API will first obtain an access token to register with Azure AD the public key that is about to be generated. The token is intended to Azure DRS which registers the public key with the corresponding user and relates it to the corresponding device object. To obtain the token, the API uses the Web Account Manager API:


This API invokes the corresponding implementation for the Azure AD plug-in. For more information on the Web Account Manager and its Azure AD plug-in please look for a future post about How SSO works in Windows 10.

Users will see an MFA challenge depending on some conditions:

  1. Users on domain joined devices will see an MFA prompt. This is using username and password credentials. Please note that the November 2015 update of Windows 10 doesn’t support Microsoft Passport for Work provisioning if the user has signed into Windows using a physical or virtual smart-card. We will add this support in a future update of Windows.
  2. Users on Azure AD joined devices will NOT see an MFA prompt if the user joined the device in the first place and provided MFA at the time of join (the attribute ‘RegisteredOwners’ on the device object holds this user). Azure AD will treat the device as a second factor of authentication if the device was registered with MFA for the user who joined it. Please note that this is current service behavior as of the publishing date of this post. We have received mixed feedback about regarding registered devices as MFA. In the future we may allow it under a setting that organizations can control.
  3. Users on Azure AD joined devices who did not join the device will see an MFA prompt.

For a federated organization the MFA challenge can come from Azure AD or from their internal STS (e.g. AD FS):

Blog - MFA during NGC provisioning

After the user authenticates and the API obtains the token, it then proceeds to generate and register the Microsoft Passport for Work keys.


(2) Microsoft Passport for Work keys generation and registration with Azure AD

The registration API relies on the Microsoft Passport crypto API (part of ncrypt.dll) to generate the key and to obtain attestation data if available. Please note that the current implementation of the client and service doesn’t support attestation validation yet. We will enable this functionality in a future update of the service and/or Windows.

The keys are generally not created at this moment but obtained from a pool of keys previously generated. Pre-generation of multiple keys happens upon boot of the device and occurs in the background. Given that these are RSA 2048 bit key pairs, depending on the TPM these may take some time to generate.

After the key pair is obtained, the PIN collection UI shows up and the user is asked for a PIN. A logical container is created and the private key is placed in it:

Blog - NGC PIN collection UI

A container is a logical grouping of key material protected by a protector key which is associated with a gesture. In this case the PIN is associated with a protector key that is obtained at this time. This key securely wraps the Microsoft Passport for Work private key recently obtained. The PIN gesture is the one that can “open” the container and allow access to the key.


About key attestation

As I mentioned above, attestation validation is not yet implemented, however let me provide details on some of the mechanics behind attestation generation. Along with the corresponding public key, its related attestation data, if available, is also obtained using the crypto API. The attestation data consists of the Attestation Identity Key (AIK) certificate and a blob holding information about the user and the Microsoft Passport for Work key generated. The blob is signed by the AIK which is a special purpose RSA key that allows the TPM to offer platform authentication. The AIK in conjunction with the Endorsement Key (EK) and its certificate (from the manufacturer) is sent to Azure Certificate Services to generate the AIK certificate which has a trust that chains up to the TPM manufacturer. This trust chain is what the service will validate upon key registration.


The registration API will now take the Azure DRS access token and the key information and post it to Azure DRS to the following end-point:


Azure DRS will find the user object in the directory and add the key information to a particular multi-valued attribute. The key information will contain a reference to the device ID (both user and device IDs are obtained from the token). A user object will have one key for every device where the user has provisioned a Microsoft Passport for Work credential.


About the user’s devices UI in the Azure management portal

One more thing that may be of interest. The UI in the Azure management portal that shows devices for a given user includes devices that the user has registered in a self-service manner (via Azure AD Join or Add Work or School Account). Windows 10 domain joined devices won’t show up given that no user participates in the registration of the device with Azure AD… except, if the user has provisioned a Microsoft Passport for Work credential, the domain joined device will show up in the UI under the user’s devices.


Authentication using the Microsoft Passport for Work credential

Finally after the credential has been provisioned it can be used to authenticate to Azure AD and to AD on-premises upon sign-in to Windows. For details on how this is accomplished please look for a future post on How SSO works in Windows 10.

Authentication to AD on-premises

In terms of the support of Microsoft Passport for Work authentication against AD on-premises, the device needs to be able to reach a DC running Windows Server 2016 (as of the date of this post it is in Technical Preview 4). There is no need to have a new Domain or Forest Functional Level in the on-premises AD.

As an alternative to deploying new DCs, logon certificates using the Microsoft Passport for Work key can be deployed. In this case down-level DCs will use the certificate for authentication (as it is today with virtual smart-cards) and users will enjoy the benefits of Windows Hello. Please note that in this case Azure AD will continue using the key for authentication.

To support logon certificates using the Microsoft Passport for Work key, it is required to have System Center Configuration Manager Technical Preview (domain joined devices) or Intune (Azure AD joined devices) (additional 3rd party MDMs may have this support as well).

For more details on deployment requirements to enable authentication to on-premises AD please see section Deployment requirements in the Microsoft Passport guide in TechNet. Please also refer to related TechNet documentation here for more resources.


Once again, thanks for reading this far and being interested in these features. Please let me know your questions or comments you have.

Until next time,

Jairo Cadena (Twitter: @JairoC_AzureAD)

Posted in Uncategorized | 19 Comments

Azure AD Join: What happens behind the scenes?

In a previous post we discussed about the three ways to setup Windows 10 devices for work with Azure AD. I later covered in detail how Windows 10 domain joined devices are registered in Azure AD. In this post I want to provide some insight about what happens behind the scenes when users join devices to Azure AD (Azure AD Join).

Users can join devices to Azure AD in two ways: 1) through the out-of-box experience (OOBE) the very first time a device is configured (or after a device reset to factory settings) or 2) through Settings after configuring the device with a Microsoft account (e.g. Hotmail) or local account.

In both cases what happens behind the scenes is fundamentally the same:

  1. User chooses to join device to Azure AD.
  2. User authenticates and provides an MFA proof (if configured).
  3. User accepts terms from MDM system (if applicable).
  4. Device registers with Azure AD.
  5. Device enrolls into MDM system and gets sign-in policy (if applicable).
  6. User signs into Windows.
  7. User provisions Microsoft Passport for Work.
  8. Device encryption is enabled and BitLocker key is escrowed to Azure AD.
  9. User enterprise settings are applied.

Let’s take a look at the details of what happens at each phase.


(1) User chooses to join device to Azure AD

When a user turns a device for the first time the user will see the OOBE. Once the user has gone through the initial pages like choosing language/region, accepting legal terms and connecting to the WiFi, the user sees the experience that allows the user to configure the device with a particular account.

The first detail to know is that this experience is web driven and runs under a particular “temporal” user that is created just before the experience shows. This differs from Windows 7/8.1 where all pages are local and run as SYSTEM up to the point of user logon.

Blog - OOBE in Win10 vs down-level

Web pages are rendered in a special host called the Cloud eXperience Host (CXH) which has access to particular WinRT APIs needed for setting up the device.

Once the CXH is launched it navigates to a web app that will orchestrate the setup process. If the device runs Windows Professional the user will see a page presenting the option to configure the device as work-owned (using a work account) or personal (using a Microsoft account). If the device runs Windows Enterprise or Windows Home this page won’t show but instead will default to work-owned or personal respectively.

Blog - Ownership page

Once the user has chosen to configure the device as work-owned, the user will have the option to join the device to Azure AD or to create a local account. The current experience shows the option to join the device to a domain (traditional Domain Join) however this option will guide the user to setup a local account for the user to run Domain Join via Settings afterwards.

Blog - Join options page

Please note that we are working on improving this experience on a future update of Windows based on feedback we have received from you.

If the user runs Azure AD Join from Settings (after setting up the device as personal or with a local account) the user will see the experience described from this point on.

After choosing Azure AD Join the CXH will navigate to the Azure AD Join web app that is hosted in the following location:

This web app is mainly “client” code in the form of HTML and JavaScript that calls particular WinRT APIs in the system via the CXH.


(2) User authenticates and provides an MFA proof if configured

Now, the web app will reach out to Azure AD to discover auth end-points by retrieving the OpenID configuration:


Configuration is retrieved by obtaining the following JSON document:

 "response_types_supported":["code","id_token","code id_token","token id_token","token"],

The web app will build a sign-in request using the discovered authorization endpoint to obtain a token to Azure DRS:


A few things to note:

  1. The value of the parameter client_id corresponds to the one of Azure DRS. This is interesting because the redirect URI is not the Azure DRS end-point but the Azure AD Join web app. In this special case the Azure AD Join web app is considered a client of Azure DRS.
  2. The token requested is an ID token. This is because the Azure AD Join web app needs to get claims from the token that need to pass to APIs for discovery, registration and MDM enrollment. Remember that the Azure AD Join web app is considered a client of Azure DRS.
  3. There is a parameter particular to Windows to specify the API version. The value of 2.0 allows obtaining MDM related URLs (for later use) as claims in the ID token.

The user will see the sign-in page where to enter credentials:

Blog - Sign-in page AADJ - 1

Once the user types the username the page will discover the corresponding realm information. This will determine whether the user needs to be redirected to a different STS (Secure Token Service) like an AD FS on-premises. This is done by retrieving realm information about the user’s domain name:


The following is an example of a JSON object for the realm information for a federated tenant:


If the tenant is federated the user will see the on-premises STS sign-in page where user can enter credentials . If the tenant is managed the user will be able to enter the password directly in the same page. In either case, if MFA has been configured the user will be challenged for additional factors of auth before proceeding.

Blog - Sign-in page AD FS - 1

For managed tenants only, an authentication buffer is created locally and temporary cached for automatic sign-in of the user to Windows at the end of OOBE (this doesn’t happen if run from Settings which will require a sign-out and a manual sign-in by the user). Federated tenant users will need to authenticate to the Windows logon UI after OOBE has completed.

Credentials are posted to Azure AD for authentication to the login end-point along with a few parameters indicating that this is a CXH driven authentication. This is useful to tweak some behaviors on the service side:

Note that it indicates where the join is run from (Settings or OOBE), the version of the host (to accommodate for future behaviors) and the platform (Desktop or Mobile).

After authentication succeeds, an ID token is generated and posted back to the Azure AD Join web app. The following is an example of the contents of the token:

 upn : ""
 instance : "NA"
 amr : ["pwd","mfa"]
 tid : "df5be8b1-f322-456c-acff-b13066d72402"
 sid : "S-1-12-1-1875800440-1278975369-1393086615-305892544"
 nbf : 1453828246
 ver : "1.0"
 mdm_enrollment_url : ""
 family_name : "Cadena"
 sub : "4ySzMn-D18vwlmB4lWNipSg7Y5-qDVg9g41XVyoRvF4"
 user_setting_sync_url : "Discovery:"
 onprem_sid : "S-1-5-21-1515794938-1370939529-2107639213-1112"
 oid : "6fce7178-9d89-4c3b-97d0-0853c08c3b12"
 exp : 1453832146
 given_name : "Jairo"
 iat : 1453828246
 iss : ""
 aud : "dd762716-544d-4aeb-a526-687b73838a22"
 name : "Jairo Cadena"
 unique_name : ""
 tenant_display_name : "Microsoft"
 primary_sid : "S-1-5-21-1515794938-1370939529-2107639213-1112"

Please note that this information is cached locally in the device and is accessible after device registration completes through the following APIs in dsreg.dll:


The following claims in particular contain URLs which are used later on to complete configuration of the device.


To know how, please keep reading🙂.


(3) User accepts terms from MDM (if applicable)

The next step is for the user to accept the terms from the MDM. If there is a corresponding URL configured in Azure AD for the MDM app for this user, the ID token will contain a claim mdm_tou_url. For more information about how these URLs are setup see the post in the Active Directory blog about Windows 10 Azure AD and Microsoft Intune MDM enrollment.

If present the web app will navigate to the URL and the user will be presented with the terms of acceptance.

Upon acceptance the page posts back an acceptance buffer that the web app will use later when calling the MDM enrollment API.


(4) Device registers with Azure AD

Via JavaScript the web app calls a WinRT worker API that in turn calls APIs for discovery of the registration service, device registration and MDM enrollment:


This API first calls a “discovery” API to obtain information about the registration service (i.e. Azure DRS). This API is an internal Win32 API implemented in dsreg.dll which retrieves the discovery data document from:

This document contains information about Azure DRS registration and authentication end-points including the federation STS end-point (if configuration is federated), the Azure DRS URI, the end-point for Microsoft Passport provisioning, etc. One example of this document is shown below:

Please note that some of these URLs/URIs are added to the cache data accessible by the DsrGetJoinInfoEx API after device registration completes (not the DsrGetJoinInfo).

With the discovery data and the ID token obtained during authentication the worker API then calls another API to perform device registration. This is another internal Win32 API in dsreg.dll which does the following:

  1. Generates a key pair for the device certificate.
  2. Generates a certificate signing request (CSR) using the key pair above (signs CSR data with private key plus includes public key in request).
  3. Generates a second key pair that will be used to bind SSO tokens physically to the device when authenticating to Azure AD later on. This key is typically called the storage/transport key (Kstk) and is derived from the SRK (Storage Root Key) of the device TPM. The way the binding of the SSO token to the device is achieved is by storing into the TPM a corresponding symmetric session key (encrypted to the storage/transport key) issued along with the SSO token upon auth to Azure AD. Along with the key pair, obtains attestation data in the form of a blob. For more details about how this please look for a couple of future posts where I will talk about SSO in Windows 10 devices and Internals of Microsoft Passport for Work.
  4. Sends a device registration request to Azure DRS (to end-point obtained from discovery document) passing along the ID token, the generated CSR and the public portion of the storage/transport key along with its attestation data.

Once the request comes to Azure DRS, the service will validate the token, will create a corresponding device object in Azure AD and will generate and send back a certificate to the device. The API in turn will install the certificate into the LocalMachine\MY store.

Using Windows PowerShell you can easily spot this certificate checking for the CN=MS-Organization-Access particular issuer:

PS C:\> dir Cert:\LocalMachine\My\ | where { $_.Issuer -match "CN=MS-Organization-Access" } | fl

Subject      : CN=fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
Issuer       : DC=net + DC=windows + CN=MS-Organization-Access + OU=82dbaca4-3e81-46ca-9c73-0950c1eaca97
Thumbprint   : A948413B32FA0A6435275693D4136BE10DFB4E97
FriendlyName :
NotBefore    : 1/30/2016 10:27:39 AM
NotAfter     : 1/27/2026 10:57:39 AM
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,

Also using MSOL Devices cmdlets you can query the device object in Azure AD:

PS C:\> Get-MsolDevice -DeviceId fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
Enabled                       : True
ObjectId                      : 3772980f-8553-402f-b092-7bd35395a6bd
DeviceId                      : fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
DisplayName                   : DESKTOP-51PBLPR
DeviceObjectVersion           : 2
DeviceOsType                  : Windows
DeviceOsVersion               : Windows 10
DeviceTrustType               : Azure AD Joined
DeviceTrustLevel              : Compliant
DevicePhysicalIds             : {}
ApproximateLastLogonTimestamp : 1/30/2016 6:57:39 PM
AlternativeSecurityIds        : {X509:<SHA1-TP-PUBKEY>A948413B32FA0A6435275693D4136BE10DFB4E97aOQeN/3X9Ak0C6mIWQSOeM17t
DirSyncEnabled                :
LastDirSyncTime               :
RegisteredOwners              : {}
GraphDeviceObject             : Microsoft.Azure.ActiveDirectory.GraphClient.Device

A few things to highlight:

  1. DeviceId is a GUID generated by Azure DRS. Note that this is the same value in the Subject field of the certificate.
  2. AlternativeSecurityIds contains the certificate thumbprint with a specific scheme format (i.e. “X509:<SHA1-TP-PUBKEY>:” + thumbprint). This is how Azure AD will find the device object when the device presents the certificate upon authentication.
  3. The storage/transport key is stored in the device object in an attribute non-visible through Graph API.


(5) Device enrolls into MDM system and gets policy

Upon successful registration the worker API calls the MDM enrollment API passing along the following:

  1. An access token to the MDM enrollment service (MDM application in Azure AD).
  2. The acceptance of terms blob obtained from the corresponding MDM page (if present).

To obtain the MDM access token it first obtains an auth code by authenticating to the MDM enrollment service application silently relying on SSO cookies obtained previously during authentication to Azure DRS:


A few things to note:

  1. Client ID corresponds to the one of the MDM app in Azure AD.
  2. The response type requested is a code.
  3. The resource is the value for the mdm_enrollment_url claim in the ID token.

The worker API will then use the code to obtain an access token for enrollment to happen. It does so by posting the code to the token end-point:


The worker API will get back a bearer token with an access token, an ID token and a refresh token. It extracts the access token and passes it to the MDM API.

MDM enrollment occurs and sign-in policy is obtained as part of the payload coming from enrollment.


(6) User signs into Windows

Once MDM enrollment completes it is time for the user to sign in. The user is automatically signed in if the tenant is managed (i.e. no federation with an on-premises STS). This is accomplished by taking the authentication buffer obtained during authentication to Azure DRS (step #2 above) and passing it to the LSA to the Cloud Authentication Provider which in turn authenticates both the user and the device with Azure AD. For more information about how this works in detail look for a future post on SSO in Windows 10 devices.

Please note that for a future update of Windows we have plans to extend the user’s automatic sign-in behavior to federated tenants as well.


(7) User provisions Microsoft Passport for Work

User provisions Microsoft Passport for Work for a secure and convenient sign-in to Windows using Windows Hello, a user’s gesture that includes a PIN, finger-print, iris or facial recognition.

I won’t delve into this today as this subject deserves a full post. Please look for a future post about Internals of Microsoft Passport for Work for complete details on what happens behind the scenes.


(8) Device encryption is enabled and BitLocker key is escrowed to Azure AD

If the device is InstantGo capable (always on, always connected, like the Surface or Surface Pro), device disk encryption is enabled and the key is sent to Azure AD to be registered in the corresponding device object.

This is done by the BitLocker Drive Encryption Service (BDESVC) which uses the following end-point discoverable through the DsrGetJoinInfoEx API to write the key in Azure AD:


The way the service authenticates the device to the end-point is by relying on the SSO capabilities of Windows 10. For more information about this please look for a future post about SSO in Windows 10 devices.


(9) User enterprise settings are applied.

One last point to mention the Enterprise Roaming of Settings capability. As of the date of this post it is a capability that is still on Private Preview (soon will be available for Public Preview). This component will authenticate to the Enterprise Roaming of Settings service using the SSO capabilities of Windows 10.

Once authenticated settings are retrieved and applied to the local device. It will rely on information returned by DsrGetJoinInfo to reach out to the service (i.e. user_setting_sync_url claim of ID token initially obtained, accessible through the DsrGetJoinInfo API).


Final thoughts

I hope this detail gives you a good idea about how Azure AD Join works. Please also let me know what you would like to see posted in future entries.

Again thanks for reading this far🙂.

See you soon,

Jairo (Twitter: JairoC_AzureAD)

Posted in Uncategorized | 40 Comments

How Domain Join is different in Windows 10 with Azure AD

In the previous post I talked about the three ways to set up devices for work with Azure AD. In this post I will talk about Domain Join and how additional capabilities are enabled in Windows 10 when Azure AD is present.

Domain Join until now

Domain Join has been deployed by many of you since the beginning of this millennium (although Domain Join existed even before AD was born and Windows NT was around).

Domain Join adds a computer to a particular realm, the Active Directory domain. The computer gets a unique identity and a channel is created so admins can reach out to the computer for settings and policy purposes (a.k.a. Group Policy).

When the computer is physically in the domain network it authenticates to the domain through a domain controller (DC). The computer participates in authorization decisions when accessing other resources in the domain. Users who sign-in to these computers using their AD accounts get authenticated to the domain as well.

Domain Join in Windows 10 and Azure AD

None of the existing behaviors for Domain Join change in Windows 10, however new capabilities light up when Azure AD is in the picture:

  1. Users don’t see additional authentication prompts when accessing work resources (a.k.a. SSO). Users enjoy SSO to Azure AD apps even when not connected to the domain network.
  2. Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a Microsoft account (e.g. Hotmail) to see settings across devices.
  3. Access to Windows Store for Business using AD account. Users can choose from an inventory of applications pre-selected by the organization.
  4. Microsoft Passport for Work and Windows Hello for secure and convenient access to work resources.
  5. Restriction of access to apps from only devices that meet compliance policy.

Domain joined devices will automatically register to Azure AD and avail of the above mentioned experiences. You can enable this functionality in your organization quite easily through a particular Group Policy. Note that you need to have the latest version of Azure AD Connect (AAD Connect). Look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

To understand how this process works let’s consider the following illustration:

Blog - Windows 10 and Domain Join Registration



(1) Policy signals device to start auto-registration with Azure AD

When the policy Register domain computers as devices is pushed down to the computer via Group Policy the device registration process will trigger. This policy is found at:

Computer Configuration/Policies/Administrative Templates/Windows Components/Device Registration

Please notice that if you are using the Group Policy management console from Windows Server 2012 R2 the policy name is Automatically workplace join client computers and is found at:

Computer Configuration/Policies/Administrative Templates/Windows Components/Workplace Join

The registry key value for this policy in the device is the REG_DWORD value autoWorkplaceJoin under:


A task registered in Task Scheduler with name Automatic-Device-Join under \Microsoft\Windows\Workplace Join triggers once the registry key value for the policy changes. A value of 1 means that auto-registration is enabled.

(2) Device queries Active Directory to get information about Azure AD tenant

The task which runs as SYSTEM reaches out to AD using the computer identity to query Azure AD tenant information stored in a Service Connection Point (SCP) object in the configuration naming context of the forest where the computer domain belongs.

The SCP is created by AAD Connect during Express installation. AAD Connect provides a PowerShell cmdlet to create the object manually. Please see more details at step-by-step to register Windows 10 domain joined devices to Azure AD. This SCP is placed in the following location (for example for the domain):

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com

The keywords multi-valued attribute on this object contains two values, one for the tenant domain name and one for the tenant ID. For example:; azureADId:6c8b4242-a724-440d-a64c-29373788285b

(3) Device authenticates itself to Azure AD via AD FS to get a token for registration

Once it gets this information, it authenticates to Azure DRS via AD FS using Windows Integrated Authentication (i.e. Kerberos auth using the computer identity). AD FS issues a token to Azure AD before Azure AD issues the final token for Azure DRS. Three claims are passed to Azure AD via the AD FS token when the computer authenticates, and are written as attributes in the newly created device object:

  1. Object GUID of computer object on-prem.
  2. SID (Security Identifier) of computer object on-prem.
  3. Claim stating that computer is domain joined.

These claims are generated thanks to three AD FS issuance transform rules that are created by AAD Connect during Express installation. To know how to create these rules manually please see more details at step-by-step to register Windows 10 domain joined devices to Azure AD.

AAD Connect will then later use these attributes in the device object to correlate it with the computer object in on-prem AD. This is needed for lifecycle of the device object which is authoritative on-prem. For more details please look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

(3b) Device authenticates itself to Azure AD (when Azure AD SSO configuration is password hash sync’ i.e. no AD FS)

When Azure AD SSO configuration is not federated but password hashes are sync’ed from on-prem, the following happens for the device to authenticate to Azure DRS:

  1. The task will create a credential in the form of a self-signed certificate and will register with the computer via LDAP in the userCertificates attribute.
  2. AAD Connect detects that the computer has registered this credential and takes it up to Azure AD in the form of a device object holding this credential, the object GUID and the computer SID.
  3. The task will use the credential in #1 to authenticate to Azure DRS directly once the device is created in #2.

Please notice that there is a inherent delay between the time the policy reaches the device and the device is ready for registration. This is because the credential that is used to complete device registration against Azure AD must flow up through AAD Connect in the absence of federation. For more details please look for a future post where I’ll discuss the AAD Connect role in enabling Windows 10 experiences.

(4) Device generates keys used in device registration

The task generates a private/public key pair to be used in a certificate signing request (CSR) to Azure DRS to obtain the certificate that the device will use to authenticate to Azure AD later on.

In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication. This removes the risk of token replay in other devices. The PRT is the token used to provide SSO when users in that device access Azure AD applications. Please look for a future post about SSO in Windows 10 devices to understand in detail how this works.

If AD FS vNext is deployed (i.e. AD FS in Windows Server 2016 which is in Production Preview as of the date of this post), the device will also obtain an AD FS PRT for SSO to AD FS applications. Please look for a future post that I will publish about AD FS support for Windows 10.

If the device has a Trusted Platform Module (TPM) the private keys will be hardware protected.

(5) Device registers with Azure AD via Azure DRS

The task sends the CSR obtaining the certificate which places in the LocalMachine\My store. A device object is created in Azure AD and the certificate thumbprint is associated with it.

In addition the public key for PRT binding is registered with the device object as well. To learn how this key is used during authentication to protect the PRT look for a future post where I’ll cover the topic of SSO in Windows 10 devices.


Final thoughts

Once registration is complete users will enjoy the new experiences described at the beginning of this post. IT will also be able to restrict access to only devices that are domain joined or only domain joined devices that are compliant. Please also look for a future post that I will publish about device conditional access and Windows devices.

Until next time,

Jairo (Twitter: @JairoC_AzureAD)

Posted in AD FS, Azure AD Connect, Azure AD Join, Device Conditional Access, Device Registration, Domain Join, Microsoft Passport for Work, On-premises Active Directory | 92 Comments

Setting up Windows 10 devices for work: Domain Join, Azure AD Join and Add Work or School Account

To enable secure access to apps and services, an organization may constrain access to only devices that are properly configured for work. When a device is setup for work, users can access securely and under compliance, apps, services and data using their work accounts (i.e. AD or Azure AD accounts).

Windows 10 offers three ways to setup a device for work: Domain Join, Azure AD Join and through Add Work or School Account for personal devices. In all cases, devices obtain an identity with Azure AD (a.k.a. register with Azure AD) and come under the control of the organization (i.e. devices are managed by the org.).

Using their work accounts on these devices, users will:

  1. Experience Single Sign-On (SSO) to Office 365 and SaaS apps from everywhere.
  2. Enjoy roaming of OS settings across joined devices.
  3. Be able to access the Windows Store for Business.
  4. Have the convenience of Microsoft Passport & Windows Hello to access work.

On the other hand, organizations will:

  1. Be able to restrict access to only devices meeting Conditional Access policy.
  2. Have piece of mind as settings and work data roam through enterprise compliant clouds. No Microsoft accounts are involved (e.g. Hotmail), and can be blocked.
  3. Reduce the risk of credential theft by implementing Microsoft Passport for Work.


Domain Join

This is the traditional way organizations have deployed Windows work devices for years. Devices are typically managed with Group Policy or System Center Configuration Manager (SCCM).

Windows 10 domain joined devices automatically register with Azure AD enabling new experiences to both users and admins. The process to join devices to the domain doesn’t need to change. Upon reboot the device attempts registration with Azure AD using its on-prem AD computer account identity. Expect a blog entry where I will describe in detail how this process works.


Azure AD Join

This is a new way for setting up work devices for work. Devices register directly with Azure AD. It provides a self-service experience for the user to setup the device from anywhere (in contrast with Domain Join which is typically done as part of an imaging process or by an admin). In a future update of Windows, Azure AD Join will offer a pre-provisioning experience for admins to prepare devices before handing them out to users.

As part of the device setup experience the device also automatically enrolls into Intune or the MDM system that has been configured in Azure AD.


Add Work or School Account

This is the way to enable personal devices to access work resources. It can be done via Settings (Accounts -> Your Account) or when the user configures an app for work. For example a user can choose to add the work account to Windows at the moment is setting up the Mail app to connect to Office 365. The user will enjoy SSO to work resources through apps and browser (Edge and IE).

In addition, adding the work account will enroll the device with Intune or the MDM system that has been configured in Azure AD.

Please note that Add Work or School Account is the replacement for the Workplace Join experience in Windows 8/8.1.

Please also note that both Domain Join and Azure AD Join allow users to sign-in/unlock devices using their work accounts. Personal devices are unlocked using Microsoft accounts (i.e. Hotmail, Live, Outlook, Xbox, etc.). Add Work or School Account doesn’t change this fact, but adds the work account on top of it (a.k.a. as a secondary account). The Microsoft account is still used for unlocking the device or for driving default Windows experiences like roaming of OS settings or Cortana.


That’s it for now. Please expect subsequent posts that describe in detail some of these concepts. See you soon!

Jairo (Twitter: @JairoC_AzureAD)

Posted in Azure AD Join, Device Conditional Access, Device Registration, Domain Join, Microsoft Passport for Work, On-premises Active Directory | 14 Comments

Hello Identity world!

Welcome to this space where I will be sharing scenarios and features related to Active Directory (AD) and Azure Active Directory (Azure AD). I will touch on areas I own or contribute as part of my Program Management role in the Identity Services Division at Microsoft.

I would love to use this blog as a two way channel where I can hear from you, customers, partners and the broader community, and in so doing, bring feedback directly to the product as we develop new experiences and features.

I will start with areas related to scenarios customers are asking for as I hear in my conversations with you, that I see would be beneficial to address in a broad approach. This includes topics around AD in Windows 10, Microsoft Passport for Work (hint: no passwords), Device Conditional Access, among others, for both the hybrid and on-premises only enterprise.

On a contextual note, I have been with the Active Directory team in both engineering and program management roles since 2005. The following Ignite/TechEd sessions show areas that I have worked on in the past:

AD in Windows 10 @ Ignite 2015:

Web Application Proxy (AD FS Proxy) @ TechEd North America 2013:

Active Directory “tricks-of-the-trade” over a decade @ TechEd North America 2011:

One more thing. I have opened a Twitter account to talk about this subject in particular. I’ll post notifications of posts to this blog there. It can also be a great way to start new conversations.

Thank you for reading this far. Let’s start this journey!

Jairo (Twitter: @JairoC_AzureAD)

Posted in AD FS, Azure AD Connect, Azure AD Join, Device Conditional Access, Device Registration, Domain Join, Microsoft Passport for Work, On-premises Active Directory | 2 Comments