diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md index d2f8d995f9..a6b919a090 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md @@ -17,10 +17,10 @@ ms.date: 08/19/2018 Device Registration is a prerequisite to Windows Hello for Business provisioning. Device registration occurs regardless of a cloud, hybrid, or on-premises deployments. For cloud and hybrid deployments, devices register with Azure Active Directory. For on-premises deployments, devices registered with the enterprise device registration service hosted by Active Directory Federation Services (AD FS). -[Azure AD joined in Managed environments](#Azure-AD-joined-in-Managed-environments)
-[Azure AD joined in Federated environments](#Azure-AD-joined-in-Federated-environments)
-[Hybrid Azure AD joined in Managed environments](#HybridAzure-AD-joined-in-Managed-environments)
-[Hybrid Azure AD joined in Federated environments](#Hybrid-Azure-AD-joined-in-Federated-environments)
+[Azure AD joined in Managed environments](#azure-ad-joined-in-managed-environments)
+[Azure AD joined in Federated environments](#azure-ad-joined-in-federated-environments)
+[Hybrid Azure AD joined in Managed environments](#hybrid-azure-ad-joined-in-managed-environments)
+[Hybrid Azure AD joined in Federated environments](#hybrid-azure-ad-joined-in-federated-environments)
@@ -47,7 +47,7 @@ Device Registration is a prerequisite to Windows Hello for Business provisioning | :----: | :----------- | |A | The most common way Azure AD joined devices register with Azure is during the out-of-box-experience (OOBE) where it loads the Azure AD join web application in the Cloud Experience Host (CXH) application. The application sends a GET request to the Azure OpenID configuration endpoint to discover authorization endpoints. Azure returns the OpenID configuration, which includes the authorization endpoints, to application as JSON document.| |B | The application builds a sign-in request for the authorization end point and collects user credentials.| -|C | After the user provides their user name (in UPN format), the application sends a GET request to Azure to discover corresponding realm information for the user. This determines if the environment is managed or federated. Azure returns the information in a JSON object. The application determines the environment is managed (non-federated).
The application redirects to the AuthURL value (on-premises STS sign-in page) in the returned JSON realm object. The application collects credentials through the STS web page.| +|C | After the user provides their user name (in UPN format), the application sends a GET request to Azure to discover corresponding realm information for the user. This determines if the environment is managed or federated. Azure returns the information in a JSON object. The application determines the environment is federated.
The application redirects to the AuthURL value (on-premises STS sign-in page) in the returned JSON realm object. The application collects credentials through the STS web page.| |D | The application POST the credential to the on-premises STS, which may require additional factors of authentication. The on-premises STS authenticates the user and returns a token. The application POSTs the token to Azure Active Directory for authentication. Azure Active Directory validates the token and returns an ID token with claims.| |E | The application looks for MDM terms of use (the mdm_tou_url claim). If present, the application retrieves the terms of use from the claim's value, present the contents to the user, and waits for the user to accept the terms of use. This step is optional and skipped if the claim is not present or if the claim value is empty.| |F | The application sends a device registration discovery request to the Azure Device Registration Service (ADRS). Azure DRS returns a discovery data document, which returns tenant specific URIs to complete device registration.| @@ -77,8 +77,8 @@ Device Registration is a prerequisite to Windows Hello for Business provisioning | Phase | Description | | :----: | :----------- | | A | The user signs in to a domain joined Windows 10 computers using domain credentials. This can be user name and password or smart card authentication. The user sign-in triggers the Automatic Device Join task.| -|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.| -|C | For the federated environments, the computer authenticates the enterprise device registration endpoint using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task. +|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines directs device registration to Azure Device Registration Service (ADRS).| +|C | For the federated environments, the computer authenticates ADFS/STS using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task. |D | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv). The application create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv. Next, the application derives second key pair from the TPM's storage root key. This is the transport key (tkpub/tkpriv).| |E | To provide SSO for on-premises federated application, the task requests an enterprise PRT from the on-premises STS. Windows Server 2016 running the Active Directory Federation Services role validate the request and return it the running task.| |F | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data. Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client. Device registration completes by receiving the device ID and the device certificate from Azure DRS. The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certificate is installed in the Personal store of the computer. With device registration complete, the task exits.| diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md index e48b498d4e..5eb46b84af 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md @@ -44,8 +44,7 @@ Because the endorsement certificate is unique for each device and does not chang > The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK. > The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations. -Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft -Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10 device. +Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10 device. Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM. @@ -121,6 +120,7 @@ The endorsement key is often accompanied by one or two digital certificates: - One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service. - The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device. + For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10. ### Related topics @@ -146,6 +146,7 @@ For more than a decade, many organizations have used the domain join to their on - 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 System Center Configuration Manager (SCCM) 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 are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory. ### Related topics @@ -167,8 +168,11 @@ The Windows Hello for Business hybrid deployment is for organizations that have [Return to Top](#Technology-and-Terms) ## Join type Join type is how devices are associated with Azure Active Directory. For a device to authenticate to Azure Active Directory it must be registered or joined. + Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure AD device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Azure AD. You can use the identity to enable or disable a device. + When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune . + Joining a device is an extension to registering a device. This means, it provides you with all the benefits of registering a device and in addition to this, it also changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account. ### Related topics @@ -229,7 +233,7 @@ The simplest way to enable authentication for on-premises directory objects in A ## Primary Refresh Token SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a Primary Refresh Token (PRT). This is a [JSON Web Token](http://openid.net/specs/draft-jones-json-web-token-07.html) containing claims about both the user and the device. -The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and domain joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.). +The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and hybrid Azure AD joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.). The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. Please also note that the PRT contains information about the device. This means that if you have any [device-based conditional access](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.