deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-18 20:03:40 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo
2024-04-23 07:26:05 -04:00
parent c6a70279c1
commit 2538daa2ad
2 changed files with 71 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
View File

@ -64,19 +64,19 @@ Sign-in to computer running Microsoft Entra Connect with access equivalent to *l
1. Open **Synchronization Services** from the **Microsoft Entra Connect** folder
1. In the **Synchronization Service Manager**, select **Help** and then select **About**
1. If the version number isn't **1.1.819** or later, then upgrade Microsoft Entra Connect to the latest version.
1. If the version number isn't **1.1.819** or later, then upgrade Microsoft Entra Connect to the latest version
### Verify the onPremisesDistinguishedName attribute is synchronized
The easiest way to verify that the onPremisesDistingushedNamne attribute is synchronized is to use the Graph Explorer for Microsoft Graph.
1. Open a web browser and navigate to [Graph Explorer](https://developer.microsoft.com/graph/graph-explorer)
1. Select **Sign in to Graph Explorer** and provide Azure credentials.
1. Select **Sign in to Graph Explorer** and provide Azure credentials
> [!NOTE]
> To successfully query the Graph API, adequate [permissions](/graph/api/user-get?) must be granted
1. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent
1. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Microsoft Entra ID. Select **Run query**.
1. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Microsoft Entra ID. Select **Run query**
> [!NOTE]
> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios.
@ -91,7 +91,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync
GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}?$select=displayName,userPrincipalName,onPremisesDistinguishedName
```
5. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute isn't synchronized the value will be **null**.
1. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute isn't synchronized the value will be **null**
#### Response
<!-- {
@ -123,7 +123,7 @@ Sign-in to a domain controller or management workstation with access equivalent
1. Expand the domain node from the navigation pane
1. Right-click the **Users** container. Hover over **New** and select **Group**
1. Type **NDES Servers** in the **Group Name** text box
1. Select **OK**.
1. Select **OK**
### Add the NDES server to the NDES Servers global security group
@ -132,7 +132,7 @@ Sign-in to a domain controller or management workstation with access equivalent
1. Open **Active Directory Users and Computers**
1. Expand the domain node from the navigation pane
1. Select **Computers** from the navigation pane. Right-click the name of the NDES server that will host the NDES server role. Select **Add to a group**
1. Type **NDES Servers** in **Enter the object names to select**. Select **OK**. Select **OK** on the **Active Directory Domain Services** success dialog.
1. Type **NDES Servers** in **Enter the object names to select**. Select **OK**. Select **OK** on the **Active Directory Domain Services** success dialog
> [!NOTE]
> For high-availability, you should have more than one NDES server to service Windows Hello for Business certificate requests. You should add additional Windows Hello for Business NDES servers to this group to ensure they receive the proper configuration.
@ -146,7 +146,7 @@ Sign-in to a domain controller or management workstation with access equivalent
1. In the navigation pane, expand the node that has your domain name. Select **Users**
1. Right-click the **Users** container. Hover over **New** and then select **User**. Type **NDESSvc** in **Full Name** and **User logon name**. Select **Next**
1. Type a secure password in **Password**. Confirm the secure password in **Confirm Password**. Clear **User must change password at next logon**. Select **Next**
1. Select **Finish**.
1. Select **Finish**
> [!IMPORTANT]
> Configuring the service's account password to **Password never expires** may be more convenient, but it presents a security risk. Normal service account passwords should expire in accordance with the organizations user password expiration policy. Create a reminder to change the service account's password two weeks before it will expire. Share the reminder with others that are allowed to change the password to ensure the password is changed before it expires.
@ -168,7 +168,7 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
1. In the content pane, double-click **Allow log on locally**. Select **Define these policy settings** and select **OK**. Select **Add User or Group...**. In the **Add User or Group** dialog box, select **Browse**. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **Administrators;Backup Operators;DOMAINNAME\NDESSvc;Users** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**. Select **OK** twice
1. In the content pane, double-click **Log on as a batch job**. Select **Define these policy settings** and select **OK**. Select **Add User or Group...**. In the **Add User or Group** dialog box, select **Browse**. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **Administrators;Backup Operators;DOMAINNAME\NDESSvc;Performance Log Users** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**. Select **OK** twice
1. In the content pane, double-click **Log on as a service**. Select **Define these policy settings** and select **OK**. Select **Add User or Group...**. In the **Add User or Group** dialog box, select **Browse**. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **NT SERVICE\ALL SERVICES;DOMAINNAME\NDESSvc** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**. Select **OK** three times
1. Close the **Group Policy Management Editor**.
1. Close the **Group Policy Management Editor**
### Configure security for the NDES Service User Rights Group Policy object
@ -177,12 +177,11 @@ The best way to deploy the **NDES Service User Rights** Group Policy object is t
Sign-in to a domain controller or management workstation with access equivalent to *domain administrator*.
1. Start the **Group Policy Management Console** (gpmc.msc)
1. Expand the domain and select the **Group Policy Object** node in the navigation pane
1. Double-click the **NDES Service User Rights** Group Policy object
1. In the **Security Filtering** section of the content pane, select **Add**. Type **NDES Servers** or the name of the security group you previously created and select **OK**
1. Select the **Delegation** tab. Select **Authenticated Users** and select **Advanced**
1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK**.
1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK**
### Deploy the NDES Service User Rights Group Policy object
@ -191,10 +190,8 @@ The application of the **NDES Service User Rights** Group Policy object uses sec
Sign-in to a domain controller or management workstation with access equivalent to *domain administrator*.
1. Start the **Group Policy Management Console** (gpmc.msc)
1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO**
3. In the **Select GPO** dialog box, select **NDES Service User Rights** or the name of the Group Policy object you previously created and select **OK**.
1. In the **Select GPO** dialog box, select **NDES Service User Rights** or the name of the Group Policy object you previously created and select **OK**
> [!IMPORTANT]
> Linking the **NDES Service User Rights** Group Policy object to the domain ensures the Group Policy object is in scope for all computers. However, not all computers will have the policy settings applied to them. Only computers that are members of the **NDES Servers** global security group receive the policy settings. All others computers ignore the Group Policy object.
@ -223,7 +220,7 @@ Sign-in to the issuing certificate authority with access equivalent to *local ad
certutil -setreg Policy\EditFlags +EDITF_ATTRIBUTEENDDATE
```
1. Restart the **Active Directory Certificate Services** service.
1. Restart the **Active Directory Certificate Services** service
### Create an NDES-Intune authentication certificate template
@ -234,7 +231,7 @@ Sign-in to the issuing certificate authority or management workstations with *Do
1. Open the **Certificate Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click the **Computer** template in the details pane and select **Duplicate Template**
1. On the **General** tab, type **NDES-Intune Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs.
1. On the **General** tab, type **NDES-Intune Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs
> [!NOTE]
> If you use different template names, you'll need to remember and substitute these names in different portions of the lab
@ -244,7 +241,7 @@ Sign-in to the issuing certificate authority or management workstations with *Do
1. Select **Object Types**, then in the window that appears, choose **Computers** and select **OK**
1. Type **NDES server** in the **Enter the object names to select** text box and select **OK**
1. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes aren't already cleared. Select **OK**
1. Select on the **Apply** to save changes and close the console.
1. Select on the **Apply** to save changes and close the console
### Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
@ -256,7 +253,7 @@ Sign in a certificate authority or management workstations with *Domain Admin eq
1. Right-click **Certificate Templates** and select **Manage**
1. Right-click the **Smartcard Logon** template and choose **Duplicate Template**
1. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list
1. On the **General** tab, type **ENTRA JOINED WHFB Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs.
1. On the **General** tab, type **ENTRA JOINED WHFB Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs
> [!NOTE]
> If you use different template names, you'll need to remember and substitute these names in different portions of the deployment
@ -266,7 +263,7 @@ Sign in a certificate authority or management workstations with *Domain Admin eq
1. On the **Request Handling** tab, select **Signature and encryption** from the **Purpose** list. Select the **Renew with same key** check box. Select **Enroll subject without requiring any user input**
1. On the **Security** tab, select **Add**. Type **NDESSvc** in the **Enter the object names to select** text box and select **OK**
1. Select **NDESSvc** from the **Group or users names** list. In the **Permissions for NDES Servers** section, select the **Allow** check box for **Read** and **Enroll**. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes aren't already cleared. Select **OK**
1. Close the console.
1. Close the console
### Publish certificate templates
@ -282,7 +279,7 @@ Sign in to the certificate authority or management workstations with an *enterpr
1. Select **Certificate Templates** in the navigation pane
1. Right-click the **Certificate Templates** node. Select **New**, and select **Certificate Template** to issue
1. In the **Enable Certificates Templates** window, select the **NDES-Intune Authentication** and **ENTRA JOINED WHFB Authentication** templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certificate authority
1. Close the console.
1. Close the console
## Install and Configure the NDES Role
@ -291,7 +288,7 @@ This section includes the following articles:
- Install the Network Device Enrollment Service Role
- Configure the NDES service account
- Configure the NDES role and Certificate Templates
- Create a Web Application Proxy for the Internal NDES URL.
- Create a Web Application Proxy for the Internal NDES URL
- Enroll for an NDES-Intune Authentication Certificate
- Configure the Web Server Certificate for NDES
- Verify the configuration
@ -304,38 +301,38 @@ Sign-in to the certificate authority or management workstations with an *Enterpr
1. Open **Server Manager** on the NDES server
1. Select **Manage**. Select **Add Roles and Features**
1. In the **Add Roles and Features Wizard**, on the **Before you begin** page, select **Next**. Select **Role-based or feature-based installation** on the **Select installation type** page. Select **Next**. Select **Select a server from the server pool**. Select the local server from the **Server Pool** list. Select **Next**.
1. In the **Add Roles and Features Wizard**, on the **Before you begin** page, select **Next**. Select **Role-based or feature-based installation** on the **Select installation type** page. Select **Next**. Select **Select a server from the server pool**. Select the local server from the **Server Pool** list. Select **Next**
![Server Manager destination server.](images/aadjCert/servermanager-destination-server-ndes.png)
4. On the **Select server roles** page, select **Active Directory Certificate Services** from the **Roles** list.
1. On the **Select server roles** page, select **Active Directory Certificate Services** from the **Roles** list
![Server Manager AD CS Role.](images/aadjCert/servermanager-adcs-role.png)
Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Select **Next**.
Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Select **Next**
![Server Manager Add Features.](images/aadjcert/servermanager-adcs-add-features.png)
5. On the **Features** page, expand **.NET Framework 3.5 Features**. Select **HTTP Activation**. Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Expand **.NET Framework 4.5 Features**. Expand **WCF Services**. Select **HTTP Activation**. Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Select **Next**.
1. On the **Features** page, expand **.NET Framework 3.5 Features**. Select **HTTP Activation**. Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Expand **.NET Framework 4.5 Features**. Expand **WCF Services**. Select **HTTP Activation**. Select **Add Features** on the **Add Roles and Feature Wizard** dialog box. Select **Next**
![Server Manager Feature HTTP Activation.](images/aadjcert/servermanager-adcs-http-activation.png)
6. On the **Select role services** page, clear the **Certificate Authority** check box. Select the **Network Device Enrollment Service**. Select **Add Features** on the **Add Roles and Features Wizard** dialog box. Select **Next**.
1. On the **Select role services** page, clear the **Certificate Authority** check box. Select the **Network Device Enrollment Service**. Select **Add Features** on the **Add Roles and Features Wizard** dialog box. Select **Next**
![Server Manager ADCS NDES Role.](images/aadjcert/servermanager-adcs-ndes-role-checked.png)
7. Select **Next** on the **Web Server Role (IIS)** page
1. On the **Select role services** page for the Web Serve role, Select the following additional services if they aren't already selected and then select **Next**.
1. Select **Next** on the **Web Server Role (IIS)** page
1. On the **Select role services** page for the Web Serve role, Select the following additional services if they aren't already selected and then select **Next**
- **Web Server > Security > Request Filtering**
- **Web Server > Application Development > ASP.NET 3.5**.
- **Web Server > Application Development > ASP.NET 4.5**. .
- **Web Server > Application Development > ASP.NET 3.5**
- **Web Server > Application Development > ASP.NET 4.5**
- **Management Tools > IIS 6 Management Compatibility > IIS 6 Metabase Compatibility**
- **Management Tools > IIS 6 Management Compatibility > IIS 6 WMI Compatibility**
![Server Manager Web Server Role.](images/aadjcert/servermanager-adcs-webserver-role.png)
9. Select **Install**. When the installation completes, continue with the next procedure. **Do not click Close**.
1. Select **Install**. When the installation completes, continue with the next procedure. **Do not click Close**
> [!IMPORTANT]
> .NET Framework 3.5 is not included in the typical installation. If the server is connected to the Internet, the installation attempts to get the files using Windows Update. If the server is not connected to the Internet, you need to **Specify an alternate source path** such as \<driveLetter>:\\Sources\SxS\
@ -392,17 +389,17 @@ Sign-in a domain controller with a minimum access equivalent to *Domain Admins*.
1. Select **Trust this user for delegation to specified services only**
1. Select **Use any authentication protocol**
1. Select **Add**
1. Select **Users or Computers...** Type the name of the *NDES Server* you use to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **HOST**. Select **OK**.
1. Select **Users or Computers...** Type the name of the *NDES Server* you use to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **HOST**. Select **OK**
![NDES Service delegation to NDES host.](images/aadjcert/ndessvcdelegation-host-ndes-spn.png)
1. Repeat steps 5 and 6 for each NDES server using this service account. Select **Add**
1. Select **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Select **OK**
1. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
1. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates
![NDES Service delegation complete.](images/aadjcert/ndessvcdelegation-host-ca-spn.png)
1. Select **OK**. Close **Active Directory Users and Computers**.
1. Select **OK**. Close **Active Directory Users and Computers**
### Configure the NDES Role and Certificate Templates
@ -426,17 +423,17 @@ Sign-in to the certificate authority or management workstations with an *Enterpr
![NDES Role Services.](images/aadjcert/ndesconfig02.png)
1. On the **Service Account for NDES** page, select **Specify service account (recommended)**. Select **Select...**. Type the user name and password for the NDES service account in the **Windows Security** dialog box. Select **Next**.
1. On the **Service Account for NDES** page, select **Specify service account (recommended)**. Select **Select...**. Type the user name and password for the NDES service account in the **Windows Security** dialog box. Select **Next**
![NDES Service Account for NDES.](images/aadjcert/ndesconfig03b.png)
1. On the **CA for NDES** page, select **CA name**. Select **Select...**. Select the issuing certificate authority from which the NDES server requests certificates. Select **Next**.
1. On the **CA for NDES** page, select **CA name**. Select **Select...**. Select the issuing certificate authority from which the NDES server requests certificates. Select **Next**
![NDES CA selection.](images/aadjcert/ndesconfig04.png)
1. On the **RA Information**, select **Next**
1. On the **Cryptography for NDES** page, select **Next**
1. Review the **Confirmation** page. Select **Configure**.
1. Review the **Confirmation** page. Select **Configure**
![NDES Confirmation.](images/aadjcert/ndesconfig05.png)
@ -501,28 +498,19 @@ Sign-in a workstation with access equivalent to a *domain user*.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**
1. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**
1. Under **MANAGE**, select **Application proxy**
1. Select **Download connector service**. Select **Accept terms & Download**. Save the file (AADApplicationProxyConnectorInstaller.exe) in a location accessible by others on the domain.
1. Select **Download connector service**. Select **Accept terms & Download**. Save the file (AADApplicationProxyConnectorInstaller.exe) in a location accessible by others on the domain
:::image type="content" alt-text="Azure Application Proxy Connectors." source="images/aadjcert/azureconsole-applicationproxy-connectors-empty.png" lightbox="images/aadjcert/azureconsole-applicationproxy-connectors-empty.png":::
1. Sign-in the computer that will run the connector with access equivalent to a *domain user*.
1. Sign-in the computer that will run the connector with access equivalent to a *domain user*
> [!IMPORTANT]
> Install a minimum of two Microsoft Entra ID Proxy connectors for each NDES Application Proxy. Strategically locate Microsoft Entra application proxy connectors throughout your organization to ensure maximum availability. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers
1. Start **AADApplicationProxyConnectorInstaller.exe**
1. Read the license terms and then select **I agree to the license terms and conditions**. Select **Install**.
1. Read the license terms and then select **I agree to the license terms and conditions**. Select **Install**
![Azure Application Proxy Connector: license terms](images/aadjcert/azureappproxyconnectorinstall-01.png)
1. Sign-in to Microsoft Azure with access equivalent to **Global Administrator**.
1. Sign-in to Microsoft Azure with access equivalent to **Global Administrator**
![Azure Application Proxy Connector: sign-in](images/aadjcert/azureappproxyconnectorinstall-02.png)
1. When the installation completes. Read the information regarding outbound proxy servers. Select **Close**.
1. When the installation completes. Read the information regarding outbound proxy servers. Select **Close**
![Azure Application Proxy Connector: read](images/aadjcert/azureappproxyconnectorinstall-03.png)
1. Repeat steps 5 - 10 for each device that will run the Microsoft Entra application proxy connector for Windows Hello for Business certificate deployments.
1. Repeat steps 5 - 10 for each device that will run the Microsoft Entra application proxy connector for Windows Hello for Business certificate deployments
#### Create a Connector Group
@ -583,8 +571,7 @@ Sign-in the NDES server with access equivalent to *local administrators*.
1. Under **Subject name**, select **Common Name** from the **Type** list. Type the internal URL used in the previous task (without the https://, for example **ndes.corp.mstepdemo.net**) and then select **Add**
1. Under **Alternative name**, select **DNS** from the **Type** list. Type the internal URL used in the previous task (without the https://, for example **ndes.corp.mstepdemo.net**). Select **Add**. Type the external URL used in the previous task (without the https://, for example **ndes-mstephendemo.msappproxy.net**). Select **Add**. Select **OK** when finished
1. Select **Enroll**
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices.
1. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices
### Configure the Web Server Role
@ -593,7 +580,7 @@ This task configures the Web Server role on the NDES server to use the server au
Sign-in the NDES server with access equivalent to *local administrator*.
1. Start **Internet Information Services (IIS) Manager** from **Administrative Tools**
1. Expand the node that has the name of the NDES server. Expand **Sites** and select **Default Web Site**.
1. Expand the node that has the name of the NDES server. Expand **Sites** and select **Default Web Site**
:::image type="content" alt-text="NDES IIS Console" source="images/aadjcert/ndes-iis-console.png" lightbox="images/aadjcert/ndes-iis-console.png":::
@ -602,13 +589,13 @@ Sign-in the NDES server with access equivalent to *local administrator*.
![NDES IIS Console: Add](images/aadjcert/ndes-iis-bindings.png)
1. Select **https** from **Type**. Confirm the value for **Port** is **443**
1. Select the certificate you previously enrolled from the **SSL certificate** list. Select **OK**.
1. Select the certificate you previously enrolled from the **SSL certificate** list. Select **OK**
![NDES IIS Console: Certificate List](images/aadjcert/ndes-iis-bindings-add-443.png)
1. Select **http** from the **Site Bindings** list. Select **Remove**
1. Select **Close** on the **Site Bindings** dialog box
1. Close **Internet Information Services (IIS) Manager**.
1. Close **Internet Information Services (IIS) Manager**
### Verify the configuration
@ -621,7 +608,7 @@ Sign-in the NDES server with access equivalent to *local administrator*.
1. Open **Server Manager**. Select **Local Server** from the navigation pane
1. Select **On** next to **IE Enhanced Security Configuration** in the **Properties** section
1. In the **Internet Explorer Enhanced Security Configuration** dialog, under **Administrators**, select **Off**. Select **OK**
1. Close **Server Manager**.
1. Close **Server Manager**
#### Test the NDES web server
@ -711,7 +698,7 @@ Sign-in a workstation with access equivalent to a *domain user*.
1. Select **Security** from the **Group type** list
1. Under **Group Name**, type the name of the group. For example, **ENTRA JOINED WHFB Certificate Users**
1. Provide a **Group description**, if applicable
1. Select **Assigned** from the **Membership type** list.
1. Select **Assigned** from the **Membership type** list
:::image type="content" alt-text="Microsoft Entra new group creation." source="images/aadjcert/azureadcreatewhfbcertgroup.png" lightbox="images/aadjcert/azureadcreatewhfbcertgroup.png":::

52
windows/security/identity-protection/hello-for-business/how-it-works-authentication.md
View File

@ -19,11 +19,11 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
|B | The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.|
|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
|B | The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.|
|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
@ -31,7 +31,7 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller.
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller.
|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
## Microsoft Entra join authentication to Active Directory using a key
@ -40,9 +40,9 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE]
> You might have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Microsoft Entra joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
@ -53,9 +53,9 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE]
> You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
@ -66,11 +66,11 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Microsoft Entra ID.
|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Microsoft Entra Kerberos and returns them to Cloud AP.
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After locating an active domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After locating an active domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Microsoft Entra hybrid join authentication using a key
@ -78,13 +78,13 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
@ -95,13 +95,13 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
> In the above deployment model, a **newly provisioned** user will not be able to sign in using Windows Hello for Business unless the device has line of sight to the domain controller.