mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 10:23:37 +00:00
Update deployment models in documentation
This commit is contained in:
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Windows Hello for Business cloud-only deployment guide
|
||||
description: Learn how to deplyo Windows Hello for Business in a cloud-only deployment scenario.
|
||||
description: Learn how to deploy Windows Hello for Business in a cloud-only deployment scenario.
|
||||
ms.date: 01/03/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
@ -28,9 +28,9 @@ ms.topic: how-to
|
||||
|
||||
## Configure Windows Hello for Business policy settings
|
||||
|
||||
When you Microsoft Entra join a device, the system attempts to automatically enroll you in Windows Hello for Business. If you want to use Windows Hello for Business in a cloud-only environment with its default settings, there's no additional configuration needed.
|
||||
When you Microsoft Entra join a device, the system attempts to automatically enroll you in Windows Hello for Business. If you want to use Windows Hello for Business in a cloud-only environment with its default settings, there's no extra configuration needed.
|
||||
|
||||
Cloud-only deployments use Microsoft Entra multifactor authentication (MFA) during Windows Hello for Business enrollment, and there's no additional MFA configuration needed. If you aren't already registered in MFA, you'll be guided through the MFA registration as part of the Windows Hello for Business enrollment process.
|
||||
Cloud-only deployments use Microsoft Entra multifactor authentication (MFA) during Windows Hello for Business enrollment, and there's no other MFA configuration needed. If you aren't already registered in MFA, you're guided through the MFA registration as part of the Windows Hello for Business enrollment process.
|
||||
|
||||
Policy settings can be configured to control the behavior of Windows Hello for Business, via configuration service provider (CSP) or group policy (GPO). In cloud-only deployments, devices are
|
||||
typically configured via an MDM solution like Microsoft Intune, using the [PassportForWork CSP][WIN-1].
|
||||
@ -38,7 +38,7 @@ typically configured via an MDM solution like Microsoft Intune, using the [Passp
|
||||
> [!NOTE]
|
||||
> Review the article [Configure Windows Hello for Business using Microsoft Intune](../configure.md#configure-windows-hello-for-business-using-microsoft-intune) to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business.
|
||||
|
||||
If the Intune tenant-wide policy is configured to *disable Windows Hello for Business*, or if devices are deployed with Windows Hello disabled, you must configure one policy setting to enable Windows Hello for Business in a cloud-only trust model:
|
||||
If the Intune tenant-wide policy is configured to *disable Windows Hello for Business*, or if devices are deployed with Windows Hello disabled, you must configure one policy setting to enable Windows Hello for Business:
|
||||
|
||||
- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business)
|
||||
|
||||
@ -80,7 +80,7 @@ To configure a device with group policy, use the [Local Group Policy Editor](/pr
|
||||
> [!TIP]
|
||||
> If you're using Microsoft Intune, and you're not using the [tenant-wide policy](../configure.md#verify-the-tenant-wide-policy), enable the Enrollment Status Page (ESP) to ensure that the devices receive the Windows Hello for Business policy settings before users can access their desktop. For more information about ESP, see [Set up the Enrollment Status Page][MEM-1].
|
||||
|
||||
Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
|
||||
## Enroll in Windows Hello for Business
|
||||
|
||||
@ -94,7 +94,7 @@ The Windows Hello for Business provisioning process begins immediately after a u
|
||||
|
||||
## Disable automatic enrollment
|
||||
|
||||
If you want to disable the automatic Windows Hello for Business enrollment prompt, you can configure your devices with a policy setting or registry key. For more information, see [Disable Windows Hello for Business enrollment](../configure.md#disable-windows-hello-for-business-enrollment).
|
||||
If you want to disable the automatic Windows Hello for Business enrollment, you can configure your devices with a policy setting or registry key. For more information, see [Disable Windows Hello for Business enrollment](../configure.md#disable-windows-hello-for-business-enrollment).
|
||||
|
||||
> [!NOTE]
|
||||
> During the out-of-box experience (OOBE) flow of a Microsoft Entra join, you are guided to enroll in Windows Hello for Business when you don't have Intune. You can cancel the PIN screen and access the desktop without enrolling in Windows Hello for Business.
|
||||
|
@ -11,7 +11,7 @@ ms.topic: tutorial
|
||||
|
||||
The Windows Hello for Business certificate-based deployments use AD FS as the certificate registration authority (CRA).
|
||||
The CRA is responsible for issuing and revoking certificates to users. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.\
|
||||
The CRA enrolls for an *enrollment agent certificate*, and the Windows Hello for Business *authentication certificate template* is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
|
||||
The CRA enrolls for an *enrollment agent certificate*, and the Windows Hello for Business *authentication certificate template* is configured to only issue certificates to requests signed with an enrollment agent certificate.
|
||||
|
||||
> [!NOTE]
|
||||
> In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint.
|
||||
@ -33,11 +33,11 @@ Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplat
|
||||
|
||||
AD FS performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
|
||||
|
||||
Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
|
||||
Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it's successful. If the certificate fails to renew, and the certificate expires, the AD FS server requests a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
|
||||
|
||||
### Group Memberships for the AD FS service account
|
||||
|
||||
The AD FS service account must be member of the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
|
||||
The AD FS service account must be member of the security group targeted by the authentication certificate template autoenrollment (for example, *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
|
||||
|
||||
> [!TIP]
|
||||
> The adfssvc account is the AD FS service account.
|
||||
@ -45,7 +45,7 @@ The AD FS service account must be member of the security group targeted by the a
|
||||
Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
|
||||
|
||||
1. Open **Active Directory Users and Computers**
|
||||
1. Search for the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*)
|
||||
1. Search for the security group targeted by the authentication certificate template autoenrollment (for example, *Window Hello for Business Users*)
|
||||
1. Select the **Members** tab and select **Add**
|
||||
1. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment > **OK**
|
||||
1. Select **OK** to return to **Active Directory Users and Computers**
|
||||
|
@ -17,7 +17,7 @@ ms.topic: tutorial
|
||||
|
||||
## Configure Windows Hello for Business policy settings
|
||||
|
||||
There are 2 policy setting required to enable Windows Hello for Business in a certificate trust model:
|
||||
There are two policy settings required to enable Windows Hello for Business in a certificate trust model:
|
||||
|
||||
- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business)
|
||||
- [Use certificate for on-premises authentication](../policy-settings.md#use-certificate-for-on-premises-authentication)
|
||||
@ -26,7 +26,7 @@ Another optional, but recommended, policy setting is:
|
||||
|
||||
- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device)
|
||||
|
||||
Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
Use the following instructions to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
|
||||
# [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo)
|
||||
|
||||
@ -91,9 +91,9 @@ For more information about the certificate trust policy, see [Windows Hello for
|
||||
|
||||
---
|
||||
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources)
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources)
|
||||
|
||||
Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
|
||||
## Enroll in Windows Hello for Business
|
||||
|
||||
@ -115,7 +115,7 @@ The AD FS registration authority verifies the key used in the certificate reques
|
||||
> [!NOTE]
|
||||
> In order for AD FS to verify the key used in the certificate request, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint.
|
||||
|
||||
The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Action Center.
|
||||
The CA validates that the certificate is signed by the registration authority. On successful validation, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Action Center.
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users don't need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
|
||||
|
@ -41,9 +41,7 @@ If you're new to AD FS and federation services:
|
||||
- Review [key AD FS concepts][SER-3] prior to deploying the AD FS farm
|
||||
- Review the [AD FS design guide][SER-4] to design and plan your federation service
|
||||
|
||||
Once you have your AD FS design ready:
|
||||
|
||||
- Review [deploying a federation server farm][SER-2] to configure AD FS in your environment
|
||||
Once you have your AD FS design ready, review [deploying a federation server farm][SER-2] to configure AD FS in your environment
|
||||
|
||||
The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
|
||||
|
||||
@ -60,7 +58,7 @@ Hybrid certificate trust deployments require the *device write-back* feature. Au
|
||||
> [!NOTE]
|
||||
> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Microsoft Entra ID and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object.
|
||||
|
||||
If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5].
|
||||
If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure to configure **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5].
|
||||
|
||||
### Public Key Infrastructure
|
||||
|
||||
|
@ -33,7 +33,7 @@ ms.topic: tutorial
|
||||
|
||||
## Deploy Microsoft Entra Kerberos
|
||||
|
||||
If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Microsoft Entra Kerberos in your organization. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business and you can skip to the [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) section.
|
||||
If you've already deployed on-premises SSO for passwordless security key sign-in, then Microsoft Entra Kerberos is already deployed in your organization. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business, and you can skip to the [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) section.
|
||||
|
||||
If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the [Enable passwordless security key sign-in][ENTRA-1] documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
|
||||
|
||||
@ -58,7 +58,7 @@ For more information about how Microsoft Entra Kerberos works with Windows Hello
|
||||
|
||||
## Configure Windows Hello for Business policy settings
|
||||
|
||||
After setting up the Microsoft Entra Kerberos object, Windows Hello for business must be enabled and configured to use cloud Kerberos trust. There are 2 policy settings required to configure Windows Hello for Business in a cloud Kerberos trust model:
|
||||
After setting up the Microsoft Entra Kerberos object, Windows Hello for business must be enabled and configured to use cloud Kerberos trust. There are two policy settings required to configure Windows Hello for Business in a cloud Kerberos trust model:
|
||||
|
||||
- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business)
|
||||
- [Use cloud trust for on-premises authentication](../policy-settings.md#use-cloud-trust-for-on-premises-authentication)
|
||||
@ -70,7 +70,7 @@ Another optional, but recommended, policy setting is:
|
||||
> [!IMPORTANT]
|
||||
> If the **Use certificate for on-premises authentication** policy is enabled, certificate trust takes precedence over cloud Kerberos trust. Ensure that the machines that you want to enable cloud Kerberos trust have this policy **not configured**.
|
||||
|
||||
Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
The following instructions explain how to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
|
||||
# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune)
|
||||
|
||||
@ -123,18 +123,18 @@ Alternatively, you can configure devices using a [custom policy][MEM-1] with the
|
||||
|
||||
---
|
||||
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources).
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources).
|
||||
|
||||
Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
|
||||
## Enroll in Windows Hello for Business
|
||||
|
||||
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy.
|
||||
The Windows Hello for Business provisioning process begins immediately after a user signs in, if the prerequisite checks pass. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy.
|
||||
|
||||
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\
|
||||
This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4].
|
||||
|
||||
The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Microsoft Entra joined.
|
||||
The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user receives a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't enforced by policy or if the device is Microsoft Entra joined.
|
||||
|
||||
> [!NOTE]
|
||||
> The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory.
|
||||
@ -145,9 +145,9 @@ The cloud Kerberos trust prerequisite check detects whether the user has a parti
|
||||
|
||||
> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."]
|
||||
|
||||
Once a user completes enrollment with cloud Kerberos trust, the Windows Hello gesture can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
|
||||
Once a user completes enrollment with cloud Kerberos trust, the Windows Hello gesture can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user signs in or unlocks with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
|
||||
|
||||
While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory.
|
||||
After enrollment, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory.
|
||||
|
||||
## Migrate from key trust deployment model to cloud Kerberos trust
|
||||
|
||||
|
@ -17,7 +17,7 @@ ms.topic: tutorial
|
||||
|
||||
## Configure Windows Hello for Business policy settings
|
||||
|
||||
There's 1 policy setting required to enable Windows Hello for Business in a key trust model:
|
||||
There's one policy setting required to enable Windows Hello for Business in a key trust model:
|
||||
|
||||
- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business)
|
||||
|
||||
@ -25,7 +25,7 @@ Another optional, but recommended, policy setting is:
|
||||
|
||||
- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device)
|
||||
|
||||
Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
The following instructions describe how to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
|
||||
# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune)
|
||||
|
||||
@ -68,9 +68,9 @@ Alternatively, you can configure devices using a [custom policy][MEM-1] with the
|
||||
|
||||
---
|
||||
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources)
|
||||
If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources)
|
||||
|
||||
Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
Other policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md).
|
||||
|
||||
## Enroll in Windows Hello for Business
|
||||
|
||||
@ -87,7 +87,7 @@ This information is also available using the `dsregcmd.exe /status` command from
|
||||
|
||||
> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."]
|
||||
|
||||
While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory.
|
||||
After enrollment, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval.
|
||||
|
@ -34,9 +34,9 @@ ms.topic: tutorial
|
||||
|
||||
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
|
||||
|
||||
Key trust deployments don't need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Microsoft Entra Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`).
|
||||
Key trust deployments don't need client-issued certificates for on-premises authentication. *Microsoft Entra Connect Sync* configures Active Directory user accounts for public key mapping, by synchronizing the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink` attribute).
|
||||
|
||||
A Windows Server-based PKI or a third-party Enterprise certification authority can be used. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1].
|
||||
A Windows Server-based PKI or a third-party Enterprise certification authority can be used. For more information, see [Requirements for domain controller certificates from a third-party CA][SERV-1].
|
||||
|
||||
[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)]
|
||||
|
||||
|
@ -4,10 +4,6 @@ ms.topic: include
|
||||
---
|
||||
|
||||
[!INCLUDE [intro](intro.md)]
|
||||
<!--
|
||||
- **Deployment type:** [!INCLUDE [tooltip-deployment-cloud](tooltip-deployment-cloud.md)]
|
||||
- **Join type:** [!INCLUDE [tootip-join-entra](tooltip-join-entra.md)]
|
||||
-->
|
||||
> - **Deployment type:** [!INCLUDE [tooltip-deployment-cloud](tooltip-deployment-cloud.md)]
|
||||
> - **Join type:** [!INCLUDE [tootip-join-entra](tooltip-join-entra.md)]
|
||||
---
|
||||
|
@ -3,20 +3,8 @@ ms.date: 01/03/2024
|
||||
ms.topic: include
|
||||
---
|
||||
|
||||
<!--
|
||||
[!INCLUDE [intro](intro.md)]
|
||||
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
|
||||
- **Trust type:** [!INCLUDE [tooltip-trust-cloud-kerberos](tooltip-trust-cloud-kerberos.md)]
|
||||
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)]
|
||||
---
|
||||
|
||||
-->
|
||||
|
||||
> [!div class="checklist"]
|
||||
>
|
||||
> **This article describes Windows Hello for Business functionalities or scenarios that apply to:**
|
||||
> - **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
|
||||
> - **Trust type:** [!INCLUDE [tooltip-trust-cloud-kerberos](tooltip-trust-cloud-kerberos.md)]
|
||||
> - **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)]
|
||||
|
||||
---
|
@ -49,9 +49,9 @@ There are three deployment models from which you can choose:
|
||||
|
||||
|| Deployment model | Description |
|
||||
|--|--|--|
|
||||
| **🔲**| **Cloud-only** | For organizations that only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint Online, OneDrive, and others. Also, since the users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in cloud services |
|
||||
| **🔲**| **Hybrid** | For organizations that have identities synchronized from Active Directory to Microsoft Entra ID. These organizations use applications registered in Microsoft Entra ID, and want a single sign-on (SSO) experience for both on-premises and Microsoft Entra resources |
|
||||
| **🔲**| **On-premises** | For organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID. These organizations use on-premises applications, integrated in Active Directory, and want an SSO user experiences when accessing them |
|
||||
| **🔲**| **Cloud-only** | For organizations that only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint Online, OneDrive, and others. Also, since the users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in cloud services. |
|
||||
| **🔲**| **Hybrid** | For organizations that have identities synchronized from Active Directory to Microsoft Entra ID. These organizations use applications registered in Microsoft Entra ID, and want a single sign-on (SSO) experience for both on-premises and Microsoft Entra resources. |
|
||||
| **🔲**| **On-premises** | For organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID. These organizations use on-premises applications, integrated in Active Directory, and want an SSO user experiences when accessing them. |
|
||||
|
||||
>[!NOTE]
|
||||
>
|
||||
|
Reference in New Issue
Block a user