mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
Delete plan dc load - 2012/2102R2
This commit is contained in:
Paolo Matarazzo
parent
973d53ba4f
commit
ef57c365a4
@ -1,99 +0,0 @@
|
||||
---
|
||||
title: Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
|
||||
description: Learn how to plan for an adequate number of Domain Controllers to support Windows Hello for Business deployments.
|
||||
ms.date: 03/10/2023
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
|
||||
ms.topic: conceptual
|
||||
---
|
||||
# Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
|
||||
|
||||
> [!NOTE]
|
||||
>There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/help/4487044/windows-10-update-kb4487044).
|
||||
|
||||
## How many is adequate
|
||||
|
||||
How can you find out how many domain controllers are needed? You can use performance monitoring on your domain controllers to determine existing authentication traffic. Windows Server 2016 and above includes the KDC AS Requests performance counter. You can use this counter to determine how much of a domain controller's load is due to initial Kerberos authentication. It's important to remember that authentication for a Windows Hello for Business key trust deployment does not affect Kerberos authentication - it remains unchanged.
|
||||
|
||||
Windows 10 or Windows 11 accomplishes Windows Hello for Business key trust authentication by mapping an Active Directory user account to one or more public keys. This mapping occurs on the domain controller, which is why the deployment needs Windows Server 2016 or later domain controllers. Public key mapping is only supported by Windows Server 2016 domain controllers and above. Therefore, users in a key trust deployment must authenticate to a Windows Server 2016 and above domain controller.
|
||||
|
||||
Determining an adequate number of Windows Server domain controllers is important to ensure you have enough domain controllers to satisfy all authentication requests, including users mapped with public key trust. What many administrators do not realize is that adding a domain controller that supports public key mapping (in this case Windows Server 2016 or later) to a deployment of existing domain controllers which do not support public key mapping (Windows Server 2008R2, Windows Server 2012R2) instantly makes that single domain controller susceptible to carrying the most load, or what is commonly referred to as "piling on". To illustrate the "piling on" concept, consider the following scenario:
|
||||
|
||||
Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment. The Kerberos AS requests load would look something like the following:
|
||||
|
||||
|
||||
|
||||
The environment changes. The first change includes DC1 upgraded to Windows Server 2016 or later to support Windows Hello for Business key-trust authentication. Next, 100 clients enroll for Windows Hello for Business using the public key trust deployment. Given all other factors stay constant, the authentication would now look like the following:
|
||||
|
||||
|
||||
|
||||
The Windows Server 2016 or later domain controller is handling 100 percent of all public key trust authentication. However, it is also handling 10 percent of password authentication. Why? This behavior occurs because domain controllers 2 - 10 only support password and certificate trust authentication; only a Windows Server 2016 and above domain controller supports public key trust authentication. The Windows Server 2016 and above domain controller still understands how to authenticate password and certificate trust authentication and will continue to share the load of authenticating those clients. Because DC1 can handle all forms of authentication, it will bear more of the authentication load, and easily become overloaded. What if another Windows Server 2016 or later domain controller is added, but without deploying Windows Hello for Business to any more clients?
|
||||
|
||||
|
||||
|
||||
Upgrading another domain controller to Windows Server 2016 or later distributes the public key trust authentication across two domain controllers - each supporting 50 percent of the load. But it doesn't change the distribution of password and certificate trust authentication. Both Windows Server 2019 domain controllers still share 10 percent of this load. Now look at the scenario when half of the domain controllers are upgraded to Windows Server 2016 or later, but the number of Windows Hello for Business clients remains the same.
|
||||
|
||||
|
||||
|
||||
Domain controllers 1 through 5 now share the public key trust authentication load where each domain controller handles 20 percent of the public key trust load but they each still handle 10 percent of the password and certificate trust authentication. These domain controllers still have a heavier load than domain controllers 6 through 10; however, the load is adequately distributed. Now look the scenario when half of the client computers are upgraded to Windows Hello for Business using a key-trust deployment.
|
||||
|
||||
|
||||
|
||||
You'll notice the distribution did not change. Each Windows Server 2016 or later domain controller handles 20 percent of the public key trust authentication. However, increasing the volume of authentication (by increasing the number of clients) increases the amount of work that is represented by the same 20 percent. In the previous example, 20 percent of public key trust authentication equated to a volume of 20 authentications per domain controller capable of public key trust authentication. However, with upgraded clients, that same 20 percent represents a volume of 100 public key trust authentications per public key trust capable domain controller. Also, the distribution of non-public key trust authentication remained at 10 percent, but the volume of password and certificate trust authentications decreased across the older domain controllers.
|
||||
|
||||
There are several conclusions here:
|
||||
|
||||
- Upgrading domain controllers changes the distribution of new authentication, but doesn't change the distribution of older authentication.
|
||||
- Upgrading domain controllers does not affect the distribution of password and certificate trust authentication because newer domain controllers can support password and certificate trust authentication.
|
||||
- Upgraded domain controllers typically carry a heavier authentication load than down-level domain controllers because they support more forms of authentication.
|
||||
- Upgrading clients to Windows Hello for Business, increases the volume of public key trust authentication distributed across domain controllers which support it and, reduces the volume of password and certificate trust authentication across all domain controllers
|
||||
- Upgrading clients to Windows Hello for Business but does not affect the distribution of authentication; only the volume of authentication.
|
||||
|
||||
The preceding was an example to show why it's unrealistic to have a "one-size-fits-all" number to describe what "an adequate amount" means. In the real world, authentication is not evenly distributed across domain controllers.
|
||||
|
||||
## Determining total AS Request load
|
||||
|
||||
Each organization needs to have a baseline of the AS request load that occurs in their environment. Windows Server provides the KDC AS Requests performance counter that helps you determine this.
|
||||
|
||||
Pick a site where you plan to upgrade the clients to Windows Hello for Business public key trust. Pick a time when authentication traffic is most significant--Monday morning is great time as everyone is returning to the office. Enable the performance counter on *all* the domain controllers in that site. Collect KDC AS Requests performance counters for two hours:
|
||||
|
||||
- A half-hour before you expect initial authentication (sign-ins and unlocks) to be significant
|
||||
- The hour you believe initial authentication to be significant
|
||||
- And a half-hour after you expect initial authentication to be significant
|
||||
|
||||
For example, if employees are scheduled to come into the office at 9:00am. Your performance capture should begin at 8:30am and end at 10:30am. Ensure your performance logs do not wrap the data. You want to see authentication trend upward, peak, and trend downward.
|
||||
|
||||
> [!NOTE]
|
||||
> To capture all the authentication traffic. Ensure that all computers are powered down to get the most accurate authentication information (computers and services authenticate at first power up--you need to consider this authentication in your evaluation).
|
||||
|
||||
Aggregate the performance data of all domain controllers. Look for the maximum KDC AS Requests for each domain controller. Find the median time when the maximum number of requests occurred for the site, this should represent when the site is experiencing the highest amount of authentication.
|
||||
|
||||
Add the number of authentications for each domain controller for the median time. You now have the total authentication for the site during a peak time. Using this metric, you can determine the distribution of authentication across the domain controllers in the site by dividing the domain controller's authentication number for the median time by the total authentication. Multiply the quotient by 10 to convert the distribution to a percentage. To validate your math, all the distributions should equal 100 percent.
|
||||
|
||||
Review the distribution of authentication. Hopefully, none of these are above 70 percent. It's always good to reserve some capacity for the unexpected. Also, the primary purposes of a domain controller are to provide authentication and handle Active Directory operations. Identify domain controllers with lower distributions of authentication as potential candidates for the initial domain controller upgrades in conjunction with a reasonable distribution of clients provisioned for Windows Hello for Business.
|
||||
|
||||
## Monitoring Authentication
|
||||
|
||||
Using the same methods described above, monitor the Kerberos authentication after upgrading a domain controller and your first phase of Windows Hello for Business deployments. Make note of the delta of authentication before and after upgrading the domain controller to Windows Server 2016 or newer. This delta is representative of authentication resulting from the first phase of your Windows Hello for Business clients. It gives you a baseline for your environment to where you can form a statement such as:
|
||||
|
||||
```"Every n Windows Hello for Business clients results in x percentage of key-trust authentication."```
|
||||
|
||||
Where *n* equals the number of clients you switched to Windows Hello for Business and *x* equals the increased percentage of authentication from the upgraded domain controller. Armed with this information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment.
|
||||
|
||||
Remember, increasing the number of clients changes the volume of authentication distributed across the Windows Server 2016 or newer domain controllers. If there is only one Windows Server 2016 or newer domain controller, there's no distribution and you are simply increasing the volume of authentication for which THAT domain controller is responsible.
|
||||
|
||||
Increasing the number of domain controllers distributes the volume of authentication, but doesn't change it. Therefore, as you add more domain controllers, the burden of authentication, for which each domain controller is responsible, decreases. Upgrading two domain controller changes the distribution to 50 percent. Upgrading three domain controllers changes the distribution to 33 percent, and so on.
|
||||
|
||||
## Strategy
|
||||
|
||||
The simplest strategy you can employ is to upgrade one domain controller and monitor the single domain controller as you continue to phase in new Windows Hello for Business key-trust clients until it reaches a 70 or 80 percent threshold.
|
||||
|
||||
Then, upgrade a second domain controller. Monitor the authentication on both domain controllers to determine how the authentication distributes between the two domain controllers. Introduce more Windows Hello for Business clients while monitoring the authentication on the two upgraded domain controllers. Once those reach your environment's designated capacity, you can upgrade another domain controller.
|
||||
|
||||
Repeat until your deployment for that site is complete. Now, monitor authentication across all your domain controllers like you did the very first time. Determine the distribution of authentication for each domain controller. Identify the percentage of distribution for which it is responsible. If a single domain controller is responsible for 70 percent of more of the authentication, you may want to consider adding a domain controller to reduce the distribution of authentication volume.
|
||||
|
||||
However, before considering this, ensure the high load of authentication is not a result of applications and services where their configuration has a statically-configured domain controller. Adding domain controllers will not resolve the additional authentication load problem in this scenario. Instead, manually distribute the authentication to different domain controllers among all the services or applications. Alternatively, try simply using the domain name rather than a specific domain controller. Each domain controller has an A record registered in DNS for the domain name, which DNS will round robin with each DNS query. It's not the best load balancer, however, it is a better alternative to static domain controller configurations, provided the configuration is compatible with your service or application.
|
||||
@ -3,7 +3,9 @@ title: Windows Hello for Business Deployment Overview
|
||||
description: Use this deployment guide to successfully deploy Windows Hello for Business in an existing environment.
|
||||
ms.date: 02/15/2022
|
||||
ms.topic: overview
|
||||
appliesto:
|
||||
---
|
||||
|
||||
# Windows Hello for Business Deployment Overview
|
||||
|
||||
Windows Hello for Business is the springboard to a world without passwords. It replaces username and password sign-in to Windows with strong user authentication based on an asymmetric key pair.
|
||||
@ -12,7 +14,7 @@ This deployment overview is to guide you through deploying Windows Hello for Bus
|
||||
|
||||
Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](hello-identity-verification.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model.
|
||||
|
||||
## Assumptions
|
||||
## Requirements
|
||||
|
||||
This guide assumes that baseline infrastructure exists which meets the requirements for your deployment. For either hybrid or on-premises deployments, it is expected that you have:
|
||||
|
||||
@ -21,12 +23,12 @@ This guide assumes that baseline infrastructure exists which meets the requireme
|
||||
- Multi-factor Authentication is required during Windows Hello for Business provisioning
|
||||
- Proper name resolution, both internal and external names
|
||||
- Active Directory and an adequate number of domain controllers per site to support authentication
|
||||
- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud Kerberos trust deployments)
|
||||
- Active Directory Certificate Services 2012 or later (Note: certificate services aren't needed for cloud Kerberos trust deployments)
|
||||
- One or more workstation computers running Windows 10, version 1703 or later
|
||||
|
||||
If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
|
||||
If you're installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
|
||||
|
||||
Do not begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
|
||||
Don't begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
|
||||
|
||||
## Deployment and trust models
|
||||
|
||||
@ -36,10 +38,10 @@ Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises
|
||||
|
||||
The trust model determines how you want users to authenticate to the on-premises Active Directory:
|
||||
|
||||
- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
|
||||
- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
|
||||
- The key-trust model is for enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
|
||||
- The cloud-trust model is also for hybrid enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and doesn't require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
|
||||
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
|
||||
- The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
|
||||
- The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers.
|
||||
|
||||
> [!Note]
|
||||
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
|
||||
@ -53,10 +55,11 @@ Following are the various deployment guides and models included in this topic:
|
||||
- [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
|
||||
- [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
|
||||
|
||||
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you will need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
|
||||
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you'll need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials aren't synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
|
||||
|
||||
## Provisioning
|
||||
|
||||
Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
|
||||
|
||||
Note that you need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data.
|
||||
> [!NOTE]
|
||||
> You must allow access to the URL `account.microsoft.com` to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL doesn't require any authentication and as such, doesn't collect any user data.
|
||||
|
||||
@ -1,17 +1,18 @@
|
||||
---
|
||||
title: Planning a Windows Hello for Business Deployment
|
||||
title: Plan a Windows Hello for Business Deployment
|
||||
description: Learn about the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of your infrastructure.
|
||||
ms.date: 09/16/2020
|
||||
ms.topic: overview
|
||||
---
|
||||
# Planning a Windows Hello for Business Deployment
|
||||
|
||||
# Plan a Windows Hello for Business Deployment
|
||||
|
||||
Congratulations! You're taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
|
||||
|
||||
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
|
||||
|
||||
> [!Note]
|
||||
>If you have an Azure tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
|
||||
> If you have a Microsoft Entra ID tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
|
||||
|
||||
## Using this guide
|
||||
|
||||
@ -46,7 +47,7 @@ There are three deployment models from which you can choose: cloud only, hybrid,
|
||||
|
||||
##### Cloud only
|
||||
|
||||
The cloud only deployment model is for organizations who only have cloud identities and do not access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint, OneDrive, and others. Also, because these users do not use on-premises resources, they do not need certificates for things like VPN because everything they need is hosted in Azure.
|
||||
The cloud only deployment model is for organizations who 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, OneDrive, and others. Also, because these users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in Azure.
|
||||
|
||||
##### Hybrid
|
||||
|
||||
@ -64,7 +65,7 @@ The hybrid deployment model is for organizations that:
|
||||
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
|
||||
|
||||
##### On-premises
|
||||
The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Microsoft Entra ID.
|
||||
The on-premises deployment model is for organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID.
|
||||
|
||||
> [!Important]
|
||||
> On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
|
||||
@ -85,7 +86,7 @@ A deployment's trust type defines how each Windows Hello for Business client aut
|
||||
|
||||
The key trust type doesn't require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
|
||||
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust doesn't require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
|
||||
|
||||
> [!NOTE]
|
||||
> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
|
||||
@ -130,7 +131,7 @@ Group Policy is the easiest and most popular way to manage Windows Hello for Bus
|
||||
|
||||
#### Modern management
|
||||
|
||||
Modern management is an emerging device management paradigm that leverages the cloud for managing domain joined and non-domain joined devices. Organizations can unify their device management into one platform and apply policy settings using a single platform
|
||||
Modern management is an emerging device management paradigm that leverages the cloud for managing domain joined and nondomain joined devices. Organizations can unify their device management into one platform and apply policy settings using a single platform
|
||||
|
||||
### Client
|
||||
|
||||
@ -161,11 +162,11 @@ Use the remainder of this guide to help with planning your deployment. As you m
|
||||
|
||||
Choose the deployment model based on the resources your users access. Use the following guidance to make your decision.
|
||||
|
||||
If your organization does not have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet.
|
||||
If your organization doesn't have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet.
|
||||
|
||||
If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet.
|
||||
|
||||
If your organization does not have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
|
||||
If your organization doesn't have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
|
||||
> [!NOTE]
|
||||
> * Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests".
|
||||
> * Migration from on-premise to hybrid deployment will require redeployment.
|
||||
@ -177,9 +178,9 @@ Microsoft Entra hybrid joined devices managed by Group Policy need the Windows S
|
||||
|
||||
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
|
||||
|
||||
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
|
||||
One trust model isn't more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
|
||||
|
||||
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
|
||||
Because the certificate trust types issues certificates, there's more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
|
||||
|
||||
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
|
||||
|
||||
@ -203,9 +204,9 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
|
||||
|
||||
### Directory Synchronization
|
||||
|
||||
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
|
||||
Windows Hello for Business is strong user authentication, which usually means there's an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there is not another directory with which the information must be synchronized.
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there isn't another directory with which the information must be synchronized.
|
||||
|
||||
If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
|
||||
|
||||
@ -213,7 +214,7 @@ If box **1a** on your planning worksheet reads **on-premises**, then write **Azu
|
||||
|
||||
### Multifactor authentication
|
||||
|
||||
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
|
||||
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and can't be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
|
||||
|
||||
@ -233,7 +234,7 @@ Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. R
|
||||
|
||||
The last option is for you to use AD FS with a third-party adapter as the second factor of authentication. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-premises**, then you have two second factor authentication options. You must use Windows Server 2016 AD FS with your choice of the on-premises Azure MFA server or with a third-party MFA adapter.
|
||||
If box **1a** on your planning worksheet reads **on-premises**, then you have two-second factor authentication options. You must use Windows Server 2016 AD FS with your choice of the on-premises Azure MFA server or with a third-party MFA adapter.
|
||||
|
||||
If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
|
||||
|
||||
@ -241,38 +242,38 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
|
||||
|
||||
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage nondomain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
|
||||
|
||||
> [!NOTE]
|
||||
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
|
||||
|
||||
Managing hybrid deployments includes two categories of devices to consider for your Windows Hello for Business deployment—domain joined and non-domain joined. All devices are registered, however, not all devices are domain joined. You have the option of using Group Policy for domain joined devices and modern management for non-domain joined devices. Or, you can use modern management for both domain and non-domain joined devices.
|
||||
Managing hybrid deployments includes two categories of devices to consider for your Windows Hello for Business deployment—domain joined and nondomain joined. All devices are registered, however, not all devices are domain joined. You have the option of using Group Policy for domain joined devices and modern management for nondomain joined devices. Or, you can use modern management for both domain and nondomain joined devices.
|
||||
|
||||
If you use Group Policy to manage your domain joined devices, write **GP** in box **2a** on your planning worksheet. Write **modern management** in box **2b** if you decide to manage non-domain joined devices; otherwise, write **N/A**.
|
||||
If you use Group Policy to manage your domain joined devices, write **GP** in box **2a** on your planning worksheet. Write **modern management** in box **2b** if you decide to manage nondomain joined devices; otherwise, write **N/A**.
|
||||
|
||||
If you use modern management for both domain and non-domain joined devices, write **modern management** in box **2a** and **2b** on your planning worksheet.
|
||||
If you use modern management for both domain and nondomain joined devices, write **modern management** in box **2a** and **2b** on your planning worksheet.
|
||||
|
||||
### Client
|
||||
|
||||
Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11. Some deployments and features are available using earlier versions of Windows 10. Others need the latest versions.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
|
||||
> [!NOTE]
|
||||
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
|
||||
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
|
||||
* Box **2a** on your planning worksheet read **modern management**.
|
||||
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
|
||||
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
|
||||
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **key trust**, and box **2a** reads **GP**.
|
||||
<em>Optionally, you may write **1511 or later</em>* in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
|
||||
<em>Optionally, you may write **1511 or later</em>* in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
|
||||
|
||||
Write **1703 or later** in box **3a** on your planning worksheet if any of the following are true.
|
||||
* Box **1a** on your planning worksheet reads **on-premises**.
|
||||
Write **N/A** in box **3b** on your planning worksheet.
|
||||
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **certificate trust**, and box **2a** reads **GP**.
|
||||
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
|
||||
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
|
||||
|
||||
### Active Directory
|
||||
|
||||
@ -284,11 +285,11 @@ Review the trust type portion of this section if box **4d** on your planning wor
|
||||
|
||||
Public key infrastructure prerequisites already exist in your planning worksheet. These conditions are the minimum requirements for any hybrid or on-premises deployment. Additional conditions may be needed based on your trust type.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, ignore the public key infrastructure section of your planning worksheet. Cloud only deployments do not use a public key infrastructure.
|
||||
If box **1a** on your planning worksheet reads **cloud only**, ignore the public key infrastructure section of your planning worksheet. Cloud only deployments don't use a public key infrastructure.
|
||||
|
||||
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
|
||||
|
||||
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
The registration authority only relates to certificate trust deployments and the management used for domain and nondomain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
|
||||
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
|
||||
|
||||
@ -321,9 +322,9 @@ Nearly all deployments of Windows Hello for Business require an Azure account.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, write **Yes** in boxes **6a** and **6b** on your planning worksheet.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments do not use the cloud directory.
|
||||
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments don't use the cloud directory.
|
||||
|
||||
Windows Hello for Business does not require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
|
||||
Windows Hello for Business doesn't require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
|
||||
|
||||
@ -331,7 +332,7 @@ If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads *
|
||||
|
||||
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
|
||||
|
||||
Modern managed devices do not require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
|
||||
Modern managed devices don't require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
|
||||
|
||||
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.3 KiB |
@ -94,8 +94,6 @@ items:
|
||||
href: hello-cert-trust-validate-deploy-mfa.md
|
||||
- name: Configure Windows Hello for Business policy settings
|
||||
href: hello-cert-trust-policy-settings.md
|
||||
- name: Planning for Domain Controller load
|
||||
href: hello-adequate-domain-controllers.md
|
||||
- name: How-to Guides
|
||||
items:
|
||||
- name: Prepare people to use Windows Hello
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user