Windows Hello For Business

Contents
Windows Hello for Business documentation

Overview
Windows Hello for Business Overview
Concepts
Passwordless Strategy
Why a PIN is better than a password
Windows Hello biometrics in the enterprise
How Windows Hello for Business works
Technical Deep Dive
Device Registration
Provisioning
Authentication
How-to Guides
Windows Hello for Business Deployment Overview
Planning a Windows Hello for Business Deployment
Deployment Prerequisite Overview
Prepare people to use Windows Hello
Deployment Guides
Hybrid Azure AD Joined Key Trust
Hybrid Azure AD Joined Key Trust Deployment
Prerequisites
New Installation Baseline
Configure Directory Synchronization
Configure Azure Device Registration
Configure Windows Hello for Business settings
Sign-in and Provisioning
Hybrid Azure AD Joined Certificate Trust
Hybrid Azure AD Joined Certificate Trust Deployment
Prerequisites
New Installation Baseline
Sign-in and Provisioning
On-premises SSO for Azure AD Joined Devices
On-premises SSO for Azure AD Joined Devices Deployment
Configure Azure AD joined devices for On-premises Single-Sign On using
Windows Hello for Business
Using Certificates for AADJ On-premises Single-sign On
On-premises Key Trust
On-premises Key Trust Deployment
Validate Active Directory Prerequisites
Validate and Configure Public Key Infrastructure
Prepare and Deploy Windows Server 2016 Active Directory Federation Services
Validate and Deploy Multi-factor Authentication (MFA) Services
Configure Windows Hello for Business policy settings
On-premises Certificate Trust
On-premises Certificate Trust Deployment
Validate Active Directory Prerequisites
Prepare and Deploy Windows Server 2016 Active Directory Federation Services
Validate and Deploy Multi-factor Authentication (MFA) Services
Configure Windows Hello for Business policy settings
Managing Windows Hello for Business in your organization
Deploying Certificates to Key Trust Users to Enable RDP
Windows Hello for Business Features
Conditional Access
PIN Reset
Dual Enrollment
Dynamic Lock
Multi-factor Unlock
Remote Desktop
Troubleshooting
Known Deployment Issues
Errors During PIN Creation
Event ID 300 - Windows Hello successfully created
Windows Hello and password changes
Reference
Technology and Terminology
Frequently Asked Questions (FAQ)
Windows Hello for Business videos
Windows Hello for Business Overview
11/2/2020 • 7 minutes to read • Edit Online
Applies to
Windows 10
In Windows 10, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs
and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses
a biometric or PIN.
NOTE
When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide
multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these
technologies into a single solution under the Windows Hello name. Customers who have already deployed these
technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find
it easier to deploy due to simplified policies, documentation, and semantics.
Windows Hello addresses the following problems with passwords:

Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.
Server breaches can expose symmetric network credentials (passwords).
Passwords are subject to replay attacks.
Users can inadvertently expose their passwords due to phishing attacks.
Windows Hello lets users authenticate to:
a Microsoft account.
an Active Directory account.
a Microsoft Azure Active Directory (Azure AD) account.
Identity Provider Services or Relying Party Services that support Fast ID Online (FIDO) v2.0 authentication (in
progress)
After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device
and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user
provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
As an administrator in an enterprise or educational organization, you can create policies to manage Windows
Hello for Business use on Windows 10-based devices that connect to your organization.
Biometric sign-in
Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or
fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to
increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have
integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices
that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users'
credentials.
Facial recognition . This type of biometric recognition uses special cameras that see in IR light, which allows
them to reliably tell the difference between a photograph or scan and a living person. Several vendors are
shipping external cameras that incorporate this technology, and major laptop manufacturers are
incorporating it into their devices, as well.
Fingerprint recognition . This type of biometric recognition uses a capacitive fingerprint sensor to scan
your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current
generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers
(whether external or integrated into laptops or USB keyboards) work with Windows 10.
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The
biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores
biometric identification data on the device, there's no single collection point an attacker can compromise to steal
biometric data. For more information about biometric authentication with Windows Hello for Business, see
Windows Hello biometrics in the enterprise.
The difference between Windows Hello and Windows Hello for

Business
Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This
use of Windows Hello is unique to the device on which it is set up, but can use a simple password hash
depending on an individual's account type. This configuration is referred to as Windows Hello
convenience PIN and it is not backed by asymmetric (public/private key) or certificate-based
authentication.
Windows Hello for Business , which is configured by Group Policy or mobile device management
(MDM) policy, always uses key-based or certificate-based authentication. This makes it much more secure
than Windows Hello convenience PIN .
Benefits of Windows Hello

Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their
user name and password have been exposed.
You may wonder how a PIN can help protect a device better than a password. Passwords are shared secrets; they
are entered on a device and transmitted over the network to the server. An intercepted account name and
password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal
those stored credentials.
In Windows 10, Windows Hello replaces passwords. When the identity provider supports keys, the Windows
Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a
device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession
of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place
during Windows Hello enrollment creates a trusted relationship between the identity provider and the user
when the public portion of the public/private key pair is sent to an identity provider and associated with a user
account. When a user enters the gesture on the device, the identity provider knows from the combination of
Hello keys and gesture that this is a verified identity and provides an authentication token that allows
Windows 10 to access resources and services.
NOTE
Windows Hello as a convenience sign-in uses regular user name and password authentication, without the user entering
the password.
Imagine that someone is looking over your shoulder as you get money from an ATM and sees the PIN that you
enter. Having that PIN won't help them access your account because they don't have your ATM card. In the same
way, learning your PIN for your device doesn't allow that attacker to access your account because the PIN is local
to your specific device and doesn't enable any type of authentication from any other device.
Windows Hello helps protect user identities and user credentials. Because the user doesn't enter a password
(except during provisioning), it helps circumvent phishing and brute force attacks. It also helps prevent server
breaches because Windows Hello credentials are an asymmetric key pair, which helps prevent replay attacks
when these keys are protected by TPMs.
How Windows Hello for Business works: key points

Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can
be bound to the device, and the token that is obtained using the credential is also bound to the device.
Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and
maps the Windows Hello public key to a user account during the registration step.
Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software,
based on the policy.
Authentication is the two-factor authentication with the combination of a key or certificate tied to a device
and something that the person knows (a PIN) or something that the person is (biometrics). The Windows
Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are
stored locally on a device. The PIN is never stored or shared.
The private key never leaves a device when using TPM. The authenticating server has a public key that is
mapped to the user account during the registration process.
PIN entry and biometric gesture both trigger Windows 10 to use the private key to cryptographically sign
data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the
user.
Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container
for keys. All keys are separated by identity providers' domains to help ensure user privacy.
Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
For details, see How Windows Hello for Business works.
Comparing key-based and certificate-based authentication

Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software.
Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can
continue to use PKI in combination with Windows Hello. Enterprises that do not use PKI or want to reduce the
effort associated with managing user certificates can rely on key-based credentials for Windows Hello but still
use certificates on their domain controllers as a root of trust.
Windows Hello for Business with a key does not support supplied credentials for RDP. RDP does not support
authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with
certificate based deployments as a supplied credential. Windows Hello for Business key trust can be used with
Windows Defender Remote Credential Guard.
Learn more
Implementing strong user authentication with Windows Hello for Business
Implementing Windows Hello for Business at Microsoft
Introduction to Windows Hello, video presentation on Microsoft Virtual Academy
Windows Hello face authentication
Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!
Windows 10: The End Game for Passwords and Credential Theft?
Related topics
Manage Windows Hello for Business in your organization
Windows Hello errors during PIN creation
Passwordless Strategy
Four steps to password freedom

Over the past few years, Microsoft has continued their commitment to enabling a world without passwords. At
Microsoft Ignite 2017, we shared our four-step approach to password freedom.
1. Develop a password replacement offering

Before you move away from passwords, you need something to replace them. With Windows 10, Microsoft
introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single
sign-on to Azure Active Directory and Active Directory.
Deploying Windows Hello for Business is the first step towards a passwordless environment. Windows Hello for
Business coexists nicely with existing password-based security. Users are likely to use Windows Hello for
Business because of its convenience, especially when combined with biometrics. However, some workflows and
applications may still need passwords. This early stage is about implementing an alternative and getting users
used to it.
2. Reduce user-visible password surface area
With Windows Hello for Business and passwords coexisting in your environment, the next step is to reduce the
password surface. The environment and workflows need to stop asking for passwords. The goal of this step is to
achieve a state where the users know they have a password, but they never use it. This state helps decondition
users from providing a password any time a password prompt shows on their computer. This is how passwords
are phished. Users who rarely, if at all, use their password are unlikely to provide it. Password prompts are no
longer the norm.
3. Transition into a passwordless deployment
Once the user-visible password surface has been eliminated, your organization can begin to transition those
users into a passwordless world. A world where:
the users never type their password
the users never change their password
the users do not know their password
In this world, the user signs in to Windows 10 using Windows Hello for Business and enjoys single sign-on to
Azure and Active Directory resources. If the user is forced to authenticate, their authentication uses Windows
Hello for Business.
4. Eliminate passwords from the identity directory
The final step of the passwordless story is where passwords simply do not exist. At this step, identity directories
no longer persist any form of the password. This is where Microsoft achieves the long-term security promise of
a truly passwordless environment.
Methodology
Four steps to password freedom provides an overall view of how Microsoft envisions the road to eliminating
passwords. But this road is frequently traveled and derailed by many. The scope of work is vast and filled with
many challenges and frustrations. Nearly everyone wants the instant gratification of achieving a passwordless
environment, but can easily become overwhelmed by any of the steps. You are not alone and Microsoft
understands. While there are many ways to accomplish freedom from passwords, here is one recommendation
based on several years of research, investigation, and customer conversations.
Prepare for the Journey
The road to being passwordless is a journey. The duration of that journey varies for each organization. It is
important for IT decision-makers to understand the criteria influencing the length of that journey.
The most intuitive answer is the size of the organization, and that would be correct. However, what exactly
determines size? One way to break down the size of the organization is by creating a summary of the:
Number of departments
Organization or department hierarchy
Number and type of applications and services
Number of work personas
Organization's IT structure
Number of departments
The number of departments within an organization varies. Most organizations have a common set of
departments such as executive leadership, human resources, accounting, sales, and marketing. Other
organizations will have those departments and additional ones such research and development or support.
Small organizations may not segment their departments this explicitly, while larger ones may. Additionally, there
may be sub-departments, and sub-departments of those sub-departments as well.
You need to know all the departments within your organization and you need to know which departments use
computers and which ones do not. It is fine if a department does not use computers (probably rare, but
acceptable). This is one less department with which you need to concern yourself. Nevertheless, ensure this
department is in your list and you have assessed that it is not applicable.
Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those
departments that will put you and your staff on the road to password freedom. Realistically, many of us lose
sight of our organizational chart and how it grows or shrinks over time. This is why you need to inventory all of
them. Also, do not forget to include external departments such as vendors or federated partners. If your
organization goes password-free, but your partners continue to use passwords and then access your corporate
resources, you should know about it and include them in your passwordless strategy.
Organization or department hierarchy
Organization and department hierarchy is the management layers within the departments or the organization
as a whole. How the device is used, what applications and how they are used, most likely differs between each
department, but also within the structure of the department. To determine the correct passwordless strategy,
you need to know these differences across your organization. An executive leader is likely to use their device
differently compared to a member of middle management in the sales department. Both of those user cases are
probably different to how an individual contributor in the customer service department uses their device.
Number and type of applications and services
The number of applications within an organization is simply astonishing and rarely is there one centralized list
that is accurate. Applications and services are the most critical items in your passwordless assessment.
Applications and services take considerable effort to move to a different type of authentication. That is not to
say changing policies and procedures is not a daunting task, but there is something to be said of updating a
company's set of standard operating procedures and security policies compared to changing 100 lines (or more)
of authentication code in the critical path of your internally developed CRM application.
Capturing the number of applications used is easier once you have the departments, their hierarchy, and their
stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You
can now associate the applications that are used by all levels within each department. You'll also want to
document whether the application is internally developed or commercially available off-the-shelf (COTS). If the
latter, document the manufacturer and the version. Also, do not forget web-based applications or services when
inventorying applications.
Number of work personas
Work personas is where the three previous efforts converge. You know the departments, the organizational
levels within each department, the numbers of applications used by each, respectively, and the type of
application. From this you want to create a work persona.
A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc.),
within a specific department to a collection of applications used. There is a high probability that you will have
many work personas. These work personas will become units of work, and you will refer to them in
documentation and in meetings. You need to give them a name.
Give your personas easy and intuitive names like Abby Accounting, Mark Marketing, or Sue Sales. If the
organization levels are common across departments, then decide on a first name that represents the common
levels in a department. For example, Abby could be the first name of an individual contributor in any given
department, while the first name Sue could represent someone from middle management in any given
department. Additionally, you can use suffixes such as (I, II, Senior, etc.) to further define departmental structure
for a given persona.
Ultimately, create a naming convention that does not require your stakeholders and partners to read through a
long list of tables or a secret decoder ring. Also, if possible, try to keep the references as names of people. After
all, you are talking about a person who is in that department and who uses that specific software.
Organization's IT structure
IT department structures can vary more than the organization. Some IT departments are centralized while
others are decentralized. Also, the road to password freedom will probably have you interacting with the client
authentication team, the deployment team, the security team, the PKI team, the Active Directory team, the cloud
team, and the list continues. Most of these teams will be your partner on your journey to password freedom.
Ensure there is a passwordless stakeholder on each of these teams, and that the effort is understood and
funded.
Assess your Organization
You have a ton of information. You have created your work personas, you have identified your stakeholders
throughout the different IT groups. Now what?
By now you can see why it is a journey and not a weekend project. You need to investigate user-visible password
surfaces for each of your work personas. Once you have identified the password surfaces, you need to mitigate
them. Resolving some password surfaces are simple - meaning a solution already exists in the environment and
it is only a matter of moving users to it. Resolution to some passwords surfaces may exist, but are not deployed
in your environment. That resolution results in a project which must be planned, tested, and then deployed. That
is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems.
Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software
development. Even with agile development methodologies, changing the way someone authenticates to an
application is critical. Without the proper planning and testing, it has the potential to severely impact
productivity.
How long does it take to become passwordless? The answer is "it depends". It depends on the organizational
alignment of a passwordless strategy. Top-down agreement that a passwordless environment is the
organization's goal makes conversations much easier. Easier conversations means less time spent convincing
people and more time spent moving forward toward the goal. Top-down agreement, as a priority within the
ranks of other on-going IT projects, helps everyone understand how to prioritize existing projects. Agreeing on
priorities should reduce and minimize manager and executive level escalations. After these organizational
discussions, modern project management techniques are used to continue the passwordless effort. The
organization allocates resources based on the priority (after they have agreed on the strategy). Those resources
will:
work through the work personas
organize and deploy user acceptance testing
evaluate user acceptance testing results for user-visible password surfaces
work with stakeholders to create solutions that mitigate user-visible password surfaces
add the solution to the project backlog and prioritize against other projects
deploy the solution
perform user acceptance testing to confirm that the solution mitigates the user-visible password surface
repeat the testing as needed
Your organization's journey to password freedom may take some time. Counting the number of work personas
and the number of applications is probably a good indicator of the investment. Hopefully, your organization is
growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go
passwordless today is n, then it is likely that to go passwordless tomorrow is n x 2 or perhaps more, n x n. Do
not let the size or duration of the project be a distraction. As you progress through each work persona, the
actions and tasks will become more familiar for you and your stakeholders. Scope the project to sizable, realistic
phases, pick the correct work personas, and soon you will see parts of your organization transition to a
passwordless state.
Where to start?
What is the best guidance for kicking off the journey to password freedom? You will want to show your
management a proof of concept as soon as possible. Ideally, you want to show this at each step of your
passwordless journey. Keeping your passwordless strategy top of mind and showing consistent progress keeps
everyone focused.
Work persona
You begin with your work personas. These were part of your preparation process. They have a persona name,
such as Abby Accounting II, or any other naming convention your organization defined. That work persona
includes a list of all the applications Abby uses to perform her assigned duties in the accounting department. To
start, you need to pick a work persona. This is the targeted work persona you will enable to climb the steps to
password freedom.
IMPORTANT
Avoid using any work personas from your IT department. This is probably the worst way to start the passwordless
journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of
scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas
for the middle or end of your journey.
Review your collection of work personas. Early in your passwordless journey, identify personas with the fewest
applications. These work personas could represent an entire department or two. These are the perfect work
personas for your proof-of-concept or pilot.
Most organizations host their proof of concept in a test lab or environment. To do that with a password-free
strategy may be more challenging and take more time. To test in a lab, you must first duplicate the environment
of the targeted persona. This could take a few days or several weeks, depending on the complexity of the
targeted work persona.
You will want to balance lab testing with providing results to management quickly. Continuing to show forward
progress on your journey to password freedom is always a good thing. If there are ways you can test in
production with low or no risk, it may be advantageous to your timeline.
The Process
The journey to password freedom is to take each work persona through each step of the process. In the
beginning, we encourage working with one persona at a time to ensure team members and stakeholders are
familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel
as resources allow. The process looks something like this:
1. Passwordless replacement offering (Step 1)
a. Identify test users representing the targeted work persona.
b. Deploy Windows Hello for Business to test users.
c. Validate that passwords and Windows Hello for Business work.
2. Reduce User-visible Password Surface (Step 2)
a. Survey test user workflow for password usage.
b. Identify password usage and plan, develop, and deploy password mitigations.
c. Repeat until all user password usage is mitigated.
d. Remove password capabilities from Windows.
e. Validate that none of the workflows need passwords.
3. Transition into a passwordless scenario (Step 3)
a. Awareness campaign and user education.
b. Include remaining users who fit the work persona.
c. Validate that none of the users of the work personas need passwords.
d. Configure user accounts to disallow password authentication.
After successfully moving a work persona to password freedom, you can prioritize the remaining work personas
and repeat the process.
Passwordless replacement offering (Step 1)
The first step to password freedom is providing an alternative to passwords. Windows 10 provides an affordable
and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to
Azure Active Directory and Active Directory.
Identify test users that represent the targeted work persona
A successful transition relies on user acceptance testing. It is impossible for you to know how every work
persona goes about their day-to-day activities, or how to accurately validate them. You need to enlist the help of
users who fit the targeted work persona. You only need a few users from the targeted work persona. As you
cycle through step 2, you may want to change a few of the users (or add a few) as part of your validation
process.
Deploy Windows Hello for Business to test users
Next, you will want to plan your Windows Hello for Business deployment. Your test users will need an alternative
way to sign-in during step 2 of the journey to becoming passwordless. Use the Windows Hello for Business
Planning Guide to help learning which deployment is best suited for your environment. Next, use the Windows
Hello for Business deployment guides to deploy Windows Hello for Business.
With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business
enrollments to the targeted work personas. The great news is that you will only need to deploy the
infrastructure once. When other targeted work personas need to provision Windows Hello for Business, you can
simply add them to a group. You will use the first work persona to validate your Windows Hello for Business
deployment.
NOTE
There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to
Azure Active Directory. Review your planning guide and deployment guide to ensure additional infrastructure is not
needed for an additional Azure joined devices.
Validate that passwords and Windows Hello for Business work

In this first step, passwords and Windows Hello for Business must coexist. You want to validate that while your
targeted work personas can sign in and unlock using Windows Hello for Business, but they can also sign-in,
unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create
frustration and confusion with your targeted user personas.
Reduce User-visible Password Surface (Step 2)
Before you move to step 2, ensure you have:
selected your targeted work persona.
identified your test users who represent the targeted work persona.
deployed Windows Hello for Business to test users.
validated passwords and Windows Hello for Business both work for the test users.
Survey test user workflow for password usage
Now is the time to learn more about the targeted work persona. You have a list of applications they use, but you
do not know what, why, when, and how frequently. This information is important as you further your progress
through step 2.
Test users create the workflows associated with the targeted work persona. Their initial goal is to do one simple
task: Document password usage. This list is not a comprehensive one, but it gives you an idea of the type of
information you want. The general idea is to learn about all the scenarios in which that work persona encounters
a password. A good approach is to ask yourself the following set of questions:
What is the name of the application that asked for a password?.
Why do they use the application that asked for a password? (Example: is there more than one application that
can do the same thing?).
What part of their workflow makes them use the application? Try to be as specific as possible (I use
application x to issue credit card refunds for amounts over y.).
How frequently do you use this application in a given day? week?
Is the password you type into the application the same as the password you use to sign-in to Windows?
Some organizations will empower their users to write this information while some may insist on having a
member of the IT department shadow them. An objective viewer may notice a password prompt that the user
overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could
miss one password prompt that could delay the transition to being passwordless.
Identify password usage and plan, develop, and deploy password mitigations
Your test users have provided you valuable information that describes the how, what, why and when they use a
password. It is now time for your team to identify each of these password use cases and understand why the
user must use a password.
Create a master list of the scenarios. Each scenario should have a clear problem statement. Name the scenario
with a one-sentence summary of the problem statement. Include in the scenario the results of your team's
investigation as to why the user is prompted by a password. Include relevant, but accurate details. If it is policy
or procedure driven, then include the name and section of the policy that dictates why the workflow uses a
password.
Keep in mind your test users will not uncover all scenarios. Some scenarios you will need to force on your users
because they are low percentage scenarios. Remember to include scenarios like:
Provisioning a new brand new user without a password.
Users who forget the PIN or other remediation flows when the strong credential is unusable.
Next, review your master list of scenarios. You can start with the workflows that are dictated by process or
policy, or you can begin with workflows that need technical solutions - whichever of the two is easier or quicker.
This will certainly vary by organization.
Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation
as a solution to your scenario. Don't worry about the implementation details for the solution. An overview of the
changes needed to reduce the password usages is all you need. If there are technical changes needed, either
infrastructure or code changes, the exact details will likely be included in the project documentation. However
your organization tracks projects, create a new project in that system. Associate your scenario to that project and
start the processes needed to get that project funded.
Mitigating password usage with applications is one of the more challenging obstacles in the passwordless
journey. If your organization develops the application, then you are in better shape the common-off-the-shelf
software (COTS).
The ideal mitigation for applications that prompt the user for a password is to enable those applications to use
an existing authenticated identity, such as Azure Active Directory or Active Directory. Work with the applications
vendors to have them add support for Azure identities. For on-premises applications, have the application use
Windows integrated authentication. The goal for your users should be a seamless single sign-on experience
where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that
store their own identities in their own databases.
Each scenario on your master list should now have a problem statement, an investigation as to why the
password was used, and a mitigation plan on how to make the password usage go away. Armed with this data,
one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make
infrastructure changes where possible. Convert in-house applications to use federated identities or Windows
integrated authentication. Work with third-party software vendors to update their software to support federated
identities or Windows integrated authentication.
Repeat until all user password usage is mitigated
Some or all of your mitigations are in place. You need to validate that your solutions have solved their problem
statements. This is where you rely on your test users. You want to keep a good portion of your first test users,
but this is a good opportunity to replace a few or add a few. Survey test users workflow for password usage. If
all goes well, you have closed most or all of the gaps. A few are likely to remain. Evaluate your solutions and
what went wrong, change your solution as needed until you reach a solution that removes your user's need to
type a password. If you are stuck, others might be too. Use the forums from various sources or your network of
IT colleagues to describe your problem and see how others are solving it. If you are out of options, contact
Microsoft for assistance.
Remove password capabilities from Windows
You believe you have mitigated all the password usage for the targeted work persona. Now comes the true test -
configure Windows so the user cannot use a password.
Windows provides two ways to prevent your users from using passwords. You can use an interactive logon
security policy to only allow Windows Hello for Business sign-in and unlocks, or you can exclude the password
credential provider.
Se c u r i t y P o l i c y
You can use Group Policy to deploy an interactive logon security policy setting to the computer. This policy
setting is found under Computer Configuration > Policies > Windows Settings > Local Policy >
Security Options . The name of the policy setting depends on the version of the operating systems you use to
configure Group Policy.
Windows Ser ver 2016 and earlier The policy name for these operating systems is Interactive logon:
Require smar t card .
Windows 10, version 1703 or later using Remote Ser ver Administrator Tools The policy name for
these operating systems is Interactive logon: Require Windows Hello for Business or smar t card .
When you enable this security policy setting, Windows prevents users from signing in or unlocking with a
password. The password credential provider remains visible to the user. If a user tries to use a password,
Windows informs the user they must use Windows Hello for Business or a smart card.
Excluding the password credential provider
You can use Group Policy to deploy an administrative template policy setting to the computer. This policy setting
is found under Computer Configuration > Policies > Administrative Templates > System > Logon
The name of the policy setting is Exclude credential providers . The value to enter in the policy to hide the
password credential provider is 60b78e88-ead8-445c-9cfd-0b87f74ea6cd .
Excluding the password credential provider hides the password credential provider from Windows and any
application that attempts to load it. This prevents the user from entering a password using the credential
provider. However, this does not prevent applications from creating their own password collection dialogs and
prompting the user for a password using custom dialogs.
Validate that none of the workflows needs passwords
This is the big moment. You have identified password usage, developed solutions to mitigate password usage,
and have removed or disabled password usage from Windows. In this configuration, your users will not be able
to use a password. Users will be blocked if any of their workflows ask them for a password. Ideally, your test
users should be able to complete all the work flows of the targeted work persona without any password usage.
Do not forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN
or cannot use their strong credential. Ensure those scenarios are validated as well.
Transition into a passwordless deployment (Step 3)
Congratulations! You are ready to transition one or more portions of your organization to a passwordless
deployment. You have validated that the targeted work persona is ready to go where the user no longer needs
to know or use their password. You are just a few steps away from declaring success.
Awareness and user education
In this last step, you are going to include the remaining users that fit the targeted work persona to the wonderful
world of password freedom. Before you do this, you want to invest in an awareness campaign.
An awareness campaign introduces the users to the new way of authenticating to their device, such as using
Windows Hello for Business. The idea of the campaign is to positively promote the change to the users in
advance. Explain the value and why your company is changing. The campaign should provide dates and
encourage questions and feedback. This campaign can coincide with user education, where you can show the
users the changes and, if your environment allows, enable the users to try out the experience.
Including remaining users that fit the work persona
You have implemented the awareness campaign for the targeted users. These users are informed and ready to
transition to being passwordless. Add the remaining users that match the targeted work persona to your
deployment.
Validate that none of the users of the work personas needs passwords
You have successfully transitioned all users for the targeted work persona to being passwordless. Monitor the
users within the work persona to ensure they do not encounter any issues while working in a passwordless
environment.
Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues
appropriately. As you triage issues, some things to consider are:
Is the reporting user performing a task outside the work persona?
Is the reported issue affecting the entire work persona, or only specific users?
Is the outage a result of a misconfiguration?
Is the outage a overlooked gap from step 2?
Each organization's priority and severity will differ. However, most organizations consider work stoppages to be
fairly significant. Your team should predefine levels of priority and severity. With each of these levels, create
service level agreements (SLAs) for each combination of severity and priority, and hold everyone accountable to
those agreements. Reactive planning enables people to spend more time on the issue and resolving it, and less
time on the process.
Resolve the issues per your service level agreements. Higher severity items may require returning some or all of
the user's password surface. Clearly this is not the end goal, but do not let this slow down your momentum
towards becoming passwordless. Refer to how you reduced the user's password surface in step 2 and progress
forward to a solution, deploying that solution and validating it.
Configure user accounts to disallow password authentication.
You transitioned all the users for the targeted work persona to a passwordless environment and you have
successfully validated all their workflows. The last step to complete the passwordless transition is to remove the
user's knowledge of the password and prevent the authenticating authority from accepting passwords.
You can change the user's password to random data and prevent domain controllers from allowing users to use
passwords for interactive sign-ins using an account configuration on the user object.
The account options on a user account includes an option -- Smar t card is required for interactive logon ,
also known as (SCRIL).
NOTE
Do not confuse the Interactive Logon security policy for SCRIL. Security policies are enforced on the client (locally). A user
account configured for SCRIL is enforced at the domain controller.
SCRIL setting for a user on Active Director y Users and Computers.
When you configure a user account for SCRIL, Active Directory changes the affected user's password to a
random 128 bits of data. Additionally, domain controllers hosting the user account do not allow the user to sign-
in interactively with a password. Also, users will no longer be troubled with needing to change their password
when it expires, because passwords for SCRIL users in domains with a Windows Server 2012 R2 or early
domain functional level do not expire. The users are effectively passwordless because:
the do not know their password.
their password is 128 random bits of data and is likely to include non-typable characters.
the user is not asked to change their password
domain controllers do not allow passwords for interactive authentication
SCRIL setting for a user in Active Director y Administrative Center on Windows Ser ver 2012.
NOTE
Although a SCRIL user's password never expires in early domains, you can toggle the SCRIL configuration on a user
account (clear the check box, save the settings, select the check box and save the settings) to generate a new random 128
bit password. However, you should consider upgrading the domain to Windows Server 2016 domain forest functional
level and allow the domain controller to do this for you automatically.
SCRIL setting for a user in Active Director y Administrative Center on Windows Ser ver 2016.
NOTE
Windows Hello for Business was formerly known as Microsoft Passport.
A u t o m a t i c p a ssw o r d c h a n g e fo r SC R I L c o n fi g u r e d u se r s
Domains configured for Windows Server 2016 domain functional level can further secure the unknown
password for SCRIL-enabled users by configuring the domain to automatically change the password for SCRIL
users.
In this configuration, passwords for SCRIL-configured users expire based on Active Directory password policy
settings. When the SCRIL user authenticates from a domain controller, the domain controller recognizes the
password has expired, and automatically generates a new random 128 bit password for the user as part of the
authentication. What is great about this feature is your users do not experience any change password
notifications or any authentication outages.
NOTE
Some components within Windows 10, such as Data Protection APIs and NTLM authentication, still need artifacts of a
user possessing a password. This configuration provides interoperability by reducing the usage surface while Microsoft
continues to close the gaps to remove the password completely.
The Road Ahead

The information presented here is just the beginning. We will update this guide with improved tools, methods,
and scenarios, like Azure AD joined and MDM managed environments. As we continue to invest in a
passwordless future, we would love to hear from you. Your feedback is important. Send us an email at
[email protected].
Applies to
Windows 10
Windows Hello in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from
(and better than) a password? On the surface, a PIN looks much like a password. A PIN can be a set of numbers,
but enterprise policy might allow complex PINs that include special characters and letters, both upper-case and
lower-case. Something like t758A! could be an account password or a complex Hello PIN. It isn't the structure of
a PIN (length, complexity) that makes it better than a password, it's how it works.
Watch Dana Huang explain why a Windows Hello for Business PIN is more secure than a password.
PIN is tied to the device

One important difference between a password and a Hello PIN is that the PIN is tied to the specific device on
which it was set up. That PIN is useless to anyone without that specific hardware. Someone who steals your
password can sign in to your account from anywhere, but if they steal your PIN, they'd have to steal your
physical device too!
Even you can't use that PIN anywhere except on that specific device. If you want to sign in on multiple devices,
you have to set up Hello on each device.
PIN is local to the device

A password is transmitted to the server -- it can be intercepted in transmission or stolen from a server. A PIN is
local to the device -- it isn't transmitted anywhere and it isn't stored on the server. When the PIN is created, it
establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for
authentication. When you enter your PIN, it unlocks the authentication key and uses the key to sign the request
that is sent to the authenticating server.
NOTE
For details on how Hello uses asymetric key pairs for authentication, see Windows Hello for Business.
PIN is backed by hardware

The Hello PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is
designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to
make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. All
Windows 10 Mobile phones and many modern laptops have TPM.
User key material is generated and available within the Trusted Platform Module (TPM) of the user device, which
protects it from attackers who want to capture the key material and reuse it. Because Hello uses asymmetric key
pairs, users credentials can't be stolen in cases where the identity provider or websites the user accesses have
been compromised.
The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. After too
many incorrect guesses, the device is locked.
PIN can be complex

The Windows Hello for Business PIN is subject to the same set of IT management policies as a password, such as
complexity, length, expiration, and history. Although we generally think of a PIN as a simple four-digit code,
administrators can set policies for managed devices to require a PIN complexity similar to a password. You can
require or block: special characters, uppercase characters, lowercase characters, and digits.
What if someone steals the laptop or phone?

To compromise a Windows Hello credential that TPM protects, an attacker must have access to the physical
device, and then must find a way to spoof the user's biometrics or guess his or her PIN—and all of this must be
done before TPM anti-hammering protection locks the device. You can provide additional protection for laptops
that don't have TPM by enabling BitLocker and setting a policy to limit failed sign-ins.
Configure BitLocker without TPM
1. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy:
Computer Configuration > Administrative Templates > Windows Components > BitLocker
Drive Encr yption > Operating System Drives > Require additional authentication at star tup
2. In the policy option, select Allow BitLocker without a compatible TPM , and then click OK.
3. Go to Control Panel > System and Security > BitLocker Drive Encr yption and select the operating
system drive to protect. Set account lockout threshold
4. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy:
Computer Configuration > Windows Settings > Security Settings > Account Policies >
Account Lockout Policy > Account lockout threshold
5. Set the number of invalid logon attempts to allow, and then click OK.
Why do you need a PIN to use biometrics?

Windows Hello enables biometric sign-in for Windows 10: fingerprint, iris, or facial recognition. When you set
up Windows Hello, you're asked to create a PIN first. This PIN enables you to sign in using the PIN when you
can't use your preferred biometric because of an injury or because the sensor is unavailable or not working
properly.
If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in,
you would have to sign in using your account and password, which doesn't provide you the same level of
protection as Hello.
Related topics
Applies to:
Windows 10
Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard
against potential spoofing through fingerprint matching and facial recognition.
NOTE
When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide
multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these
technologies into a single solution under the Windows Hello name. Customers who have already deployed these
technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find
it easier to deploy due to simplified policies, documentation, and semantics.
Because we realize your employees are going to want to use this new technology in your enterprise, we've been
actively working with the device manufacturers to create strict design and performance recommendations that
help to ensure that you can more confidently introduce Windows Hello biometrics into your organization.
How does Windows Hello work?

Windows Hello lets your employees use fingerprint or facial recognition as an alternative method to unlocking a
device. With Windows Hello, authentication happens when the employee provides his or her unique biometric
identifier while accessing the device-specific Windows Hello credentials.
The Windows Hello authenticator works to authenticate and allow employees onto your enterprise network.
Authentication doesn't roam among devices, isn't shared with a server, and can't easily be extracted from a
device. If multiple employees share a device, each employee will use his or her own biometric data on the
device.
Why should I let my employees use Windows Hello?

Windows Hello provides many benefits, including:
It helps to strengthen your protections against credential theft. Because an attacker must have both the
device and the biometric info or PIN, it's much more difficult to gain access without the employee's
knowledge.
Employees get a simple authentication method (backed up with a PIN) that's always with them, so there's
nothing to lose. No more forgetting passwords!
Support for Windows Hello is built into the operating system so you can add additional biometric devices
and polices as part of a coordinated rollout or to individual employees or groups using Group Policy or
Mobile Device Management (MDM) configurations service provider (CSP) policies.
For more info about the available Group Policies and MDM CSPs, see the Implement Windows Hello for
Business in your organization topic.
Where is Windows Hello data stored?

The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is
never sent to external devices or servers. This separation helps to stop potential attackers by providing no single
collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an
attacker was actually able to get the biometric data from a device, it cannot be converted back into a raw
biometric sample that could be recognized by the biometric sensor.
NOTE
Each sensor on a device will have its own biometric database file where template data is stored. Each database has a
unique, randomly generated key that is encrypted to the system. The template data for the sensor will be encrypted with
this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the
capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric
data on the fingerprint module instead of in the database file.
Has Microsoft set any device requirements for Windows Hello?

We've been working with the device manufacturers to help ensure a high-level of performance and protection is
met by each sensor and device, based on these requirements:
False Accept Rate (FAR). Represents the instance a biometric identification solution verifies an
unauthorized person. This is normally represented as a ratio of number of instances in a given population
size, for example 1 in 100 000. This can also be represented as a percentage of occurrence, for example,
0.001%. This measurement is heavily considered the most important with regard to the security of the
biometric algorithm.
False Reject Rate (FRR). Represents the instances a biometric identification solution fails to verify an
authorized person correctly. Usually represented as a percentage, the sum of the True Accept Rate and
False Reject Rate is 1. Can be with or without anti-spoofing or liveness detection.
Fingerprint sensor requirements
To allow fingerprint matching, you must have devices with fingerprint sensors and software. Fingerprint sensors,
or sensors that use an employee's unique fingerprint as an alternative log on option, can be touch sensors (large
area or small area) or swipe sensors. Each type of sensor has its own set of detailed requirements that must be
implemented by the manufacturer, but all of the sensors must include anti-spoofing measures (required).
Acceptable performance range for small to large size touch sensors
False Accept Rate (FAR): <0.001 – 0.002%
Effective, real world FRR with Anti-spoofing or liveness detection: <10%
Acceptable performance range for swipe sensors
False Accept Rate (FAR): <0.002%
Facial recognition sensors
To allow facial recognition, you must have devices with integrated special infrared (IR) sensors and software.
Facial recognition sensors use special cameras that see in IR light, letting them tell the difference between a
photo and a living person while scanning an employee's facial features. These sensors, like the fingerprint
sensors, must also include anti-spoofing measures (required) and a way to configure them (optional).
False Accept Rate (FAR): <0.001%
False Reject Rate (FRR) without Anti-spoofing or liveness detection: <5%
NOTE
Windows Hello face authentication does not currently support wearing a mask during enrollment or authentication.
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock you
device. The product group is aware of this behavior and is investigating this topic further. Please remove a mask if you are
wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t
allow you to remove a mask temporarily, please consider unenrolling from face authentication and only using PIN or
fingerprint.
Related topics
Applies to
Windows 10
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords.
Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud
deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active
Directory joined, or Azure Active Directory registered devices. Windows Hello for Business also works for
domain joined devices.
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business
works and some of its supporting features.
Technical Deep Dive

Windows Hello for Business is a distributed system that uses several components to accomplish device
registration, provisioning, and authentication. Use this section to gain a better understanding of each of the
categories and how they support Windows Hello for Business.
Device Registration
Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello
for Business provisioning cannot start. Registration is where the device registers its identity with the identity
provider. For cloud and hybrid deployments, the identity provider is Azure Active Directory and the device
registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider
is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration
service hosted on the federation servers (AD FS).
For more information read how device registration works.
Provisioning
Provisioning is when the user uses one form of authentication to request a new Windows Hello for Business
credential. Typically the user signs in to Windows using user name and password. The provisioning flow
requires a second factor of authentication before it will create a strong, two-factor Windows Hello for Business
credential.
Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business provisioning works.
For more information read how provisioning works.

Authentication
With the device registered and provisioning complete, users can sign-in to Windows 10 using biometrics or a
PIN. PIN is the most common gesture and is available on all computers unless restricted by policy requiring a
TPM. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for
Business credential. Neither the PIN nor the private portion of the credential are ever sent to the identity
provider, and the PIN is not stored on the device. It is user provided entropy when performing operations that
use the private portion of the credential.
Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business authentication works.
For more information read how authentication works.
Related topics
Technology and Terminology
Windows Hello for Business and Device Registration
Applies to:
Windows 10
Device Registration is a prerequisite to Windows Hello for Business provisioning. Device registration occurs
regardless of a cloud, hybrid, or on-premises deployments. For cloud and hybrid deployments, devices register
with Azure Active Directory. For on-premises deployments, devices registered with the enterprise device
registration service hosted by Active Directory Federation Services (AD FS).
Azure AD joined in Managed environments
Azure AD joined in Federated environments
Hybrid Azure AD joined in Managed environments
Hybrid Azure AD joined in Federated environments
Azure AD joined in Managed environments
P H A SE DESC RIP T IO N
A The most common way Azure AD joined devices register

with Azure is during the out-of-box-experience (OOBE)
where it loads the Azure AD join web application in the
Cloud Experience Host (CXH) application. The application
sends a GET request to the Azure OpenID configuration
endpoint to discover authorization endpoints. Azure returns
the OpenID configuration, which includes the authorization
endpoints, to application as JSON document.
B The application builds a sign-in request for the authorization

end point and collects user credentials.
C After the user provides their user name (in UPN format), the
application sends a GET request to Azure to discover
corresponding realm information for the user. This
determines if the environment is managed or federated.
Azure returns the information in a JSON object. The
application determines the environment is managed (non-
federated).
The last step in this phase has the application create an
authentication buffer and if in OOBE, temporarily caches it
for automatic sign-in at the end of OOBE. The application
POSTs the credentials to Azure Active Directory where they
are validated. Azure Active Directory returns an ID token
with claims.
D The application looks for MDM terms of use (the

mdm_tou_url claim). If present, the application retrieves the
terms of use from the claim's value, present the contents to
the user, and waits for the user to accept the terms of use.
This step is optional and skipped if the claim is not present
or if the claim value is empty.
E The application sends a device registration discovery request

to the Azure Device Registration Service (ADRS). Azure DRS
returns a discovery data document, which returns tenant
specific URIs to complete device registration.
F The application creates TPM bound (preferred) RSA 2048 bit

key-pair known as the device key (dkpub/dkpriv). The
application create a certificate request using dkpub and the
public key and signs the certificate request with using dkpriv.
Next, the application derives second key pair from the TPM's
storage root key. This is the transport key (tkpub/tkpriv).
G The application sends a device registration request to Azure

DRS that includes the ID token, certificate request, tkpub,
and attestation data. Azure DRS validates the ID token,
creates a device ID, and creates a certificate based on the
included certificate request. Azure DRS then writes a device
object in Azure Active Directory and sends the device ID and
the device certificate to the client.
H Device registration completes by receiving the device ID and

the device certificate from Azure DRS. The device ID is saved
for future reference (viewable from dsregcmd.exe /status),
and the device certificate is installed in the Personal store of
the computer. With device registration complete, the process
continues with MDM enrollment.
Return to top
Azure AD joined in Federated environments
A The most common way Azure AD joined devices register

with Azure is during the out-of-box-experience (OOBE)
where it loads the Azure AD join web application in the
Cloud Experience Host (CXH) application. The application
sends a GET request to the Azure OpenID configuration
endpoint to discover authorization endpoints. Azure returns
the OpenID configuration, which includes the authorization
endpoints, to application as JSON document.
B The application builds a sign-in request for the authorization

end point and collects user credentials.
C After the user provides their user name (in UPN format), the
application sends a GET request to Azure to discover
corresponding realm information for the user. This
determines if the environment is managed or federated.
Azure returns the information in a JSON object. The
application determines the environment is federated.
The application redirects to the AuthURL value (on-premises
STS sign-in page) in the returned JSON realm object. The
application collects credentials through the STS web page.
D The application POST the credential to the on-premises STS,

which may require additional factors of authentication. The
on-premises STS authenticates the user and returns a token.
The application POSTs the token to Azure Active Directory
for authentication. Azure Active Directory validates the
token and returns an ID token with claims.
E The application looks for MDM terms of use (the

mdm_tou_url claim). If present, the application retrieves the
terms of use from the claim's value, present the contents to
the user, and waits for the user to accept the terms of use.
This step is optional and skipped if the claim is not present
or if the claim value is empty.
F The application sends a device registration discovery request

to the Azure Device Registration Service (ADRS). Azure DRS
returns a discovery data document, which returns tenant
specific URIs to complete device registration.
G The application creates TPM bound (preferred) RSA 2048 bit

H The application sends a device registration request to Azure

DRS that includes the ID token, certificate request, tkpub,
and attestation data. Azure DRS validates the ID token,
creates a device ID, and creates a certificate based on the
included certificate request. Azure DRS then writes a device
object in Azure Active Directory and sends the device ID and
the device certificate to the client.
I Device registration completes by receiving the device ID and

the computer. With device registration complete, the process
continues with MDM enrollment.
Return to top
Hybrid Azure AD joined in Managed environments

A The user signs in to a domain joined Windows 10 computers

using domain credentials. This can be user name and
password or smart card authentication. The user sign-in
triggers the Automatic Device Join task. Note: the Automatic
Device Join tasks is triggered on domain join as well as
retried every hour. It does not solely depend on the user
sign-in.
B The task queries Active Directory using the LDAP protocol

for the keywords attribute on service connection point
stored in the configuration partition in Active Directory
(CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device
Registration
Configuration,CN=Services,CN=Configuration,DC=corp,DC=
contoso,DC=com). The value returned in the keywords
attribute determines if device registration is directed to
Azure Device Registration Service (ADRS) or the enterprise
device registration service hosted on-premises.
C For the managed environment, the task creates an initial

authentication credential in the form of a self-signed
certificate. The task write the certificate to the userCertificate
attribute on the computer object in Active Directory using
LDAP.
D The computer cannot authenticate to Azure DRS until a

device object representing the computer that includes the
certificate on the userCertificate attribute is created in Azure
Active Directory. Azure AD Connect detects an attribute
change. On the next synchronization cycle, Azure AD
Connect sends the userCertificate, object GUID, and
computer SID to Azure DRS. Azure DRS uses the attribute
information to create a device object in Azure Active
Directory.
E The Automatic Device Join task triggers with each user sign-
in or every hour, and tries to authenticate the computer to
Azure Active Directory using the corresponding private key
of the public key in the userCertificate attribute. Azure Active
Directory authenticates the computer and issues a ID token
to the computer.
F The task creates TPM bound (preferred) RSA 2048 bit key-
pair known as the device key (dkpub/dkpriv). The application
create a certificate request using dkpub and the public key
and signs the certificate request with using dkpriv. Next, the
application derives second key pair from the TPM's storage
root key. This is the transport key (tkpub/tkpriv).
G The task sends a device registration request to Azure DRS

that includes the ID token, certificate request, tkpub, and
attestation data. Azure DRS validates the ID token, creates a
device ID, and creates a certificate based on the included
certificate request. Azure DRS then updates the device object
in Azure Active Directory and sends the device ID and the
device certificate to the client.
H Device registration completes by receiving the device ID and

the computer. With device registration complete, the task
exits.
Return to top
Hybrid Azure AD joined in Federated environments

A The user signs in to a domain joined Windows 10 computers

using domain credentials. This can be user name and
password or smart card authentication. The user sign-in
triggers the Automatic Device Join task. Note: the Automatic
Device Join tasks is triggered on domain join as well as
retried every hour. It does not solely depend on the user
sign-in.
B The task queries Active Directory using the LDAP protocol

for the keywords attribute on service connection point
stored in the configuration partition in Active Directory
(CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device
Registration
Configuration,CN=Services,CN=Configuration,DC=corp,DC=
contoso,DC=com). The value returned in the keywords
attribute determines if device registration is directed to
Azure Device Registration Service (ADRS) or the enterprise
device registration service hosted on-premises.
C For the federated environments, the computer authenticates

the enterprise device registration endpoint using Windows
integrated authentication. The enterprise device registration
service creates and returns a token that includes claims for
the object GUID, computer SID, and domain joined state. The
task submits the token and claims to Azure Active Directory
where it is validated. Azure Active Directory returns an ID
token to the running task.
D The application creates TPM bound (preferred) RSA 2048 bit

E To provide SSO for on-premises federated application, the

task requests an enterprise PRT from the on-premises STS.
Windows Server 2016 running the Active Directory
Federation Services role validate the request and return it
the running task.
F The task sends a device registration request to Azure DRS

that includes the ID token, certificate request, tkpub, and
attestation data. Azure DRS validates the ID token, creates a
device ID, and creates a certificate based on the included
certificate request. Azure DRS then writes a device object in
Azure Active Directory and sends the device ID and the
device certificate to the client. Device registration completes
by receiving the device ID and the device certificate from
Azure DRS. The device ID is saved for future reference
(viewable from dsregcmd.exe /status), and the device
certificate is installed in the Personal store of the computer.
With device registration complete, the task exits.
G If Azure AD Connect device write-back is enabled, Azure AD

Connect requests updates from Azure Active Directory at its
next synchronization cycle (device write-back is required for
hybrid deployment using certificate trust). Azure Active
Directory correlates the device object with a matching
synchronized computer object. Azure AD Connect receives
the device object that includes the object GUID and
computer SID and writes the device object to Active
Directory.
Return to top
Windows Hello for Business Provisioning
Applies to: - Windows 10

Windows Hello for Business provisioning enables a user to enroll a new, strong, two-factor credential that they
can use for passwordless authentication. Provisioning experience vary based on:
How the device is joined to Azure Active Directory
The Windows Hello for Business deployment type
If the environment is managed or federated
Azure AD joined provisioning in a Managed environment
Azure AD joined provisioning in a Federated environment
Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed environment
Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Federated environment
Domain joined provisioning in an On-premises Key Trust deployment
Domain joined provisioning in an On-premises Certificate Trust deployment
NOTE
The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a
supported configuration.
Azure AD joined provisioning in a Managed environment

A The provisioning application hosted in the Cloud Experience

Host (CXH) starts provisioning by requesting an access
token for the Azure Device Registration Service (ADRS). The
application makes the request using the Azure Active
Directory Web Account Manager plug-in.
Users must provide two factors of authentication. In this
phase, the user has already provided one factor of
authentication, typically user name and password. Azure
MFA services provides the second factor of authentication. If
the user has performed Azure MFA within the last 10
minutes, such as when registering the device from the out-
of-box-experience (OOBE), then they are not prompted for
MFA because the current MFA remains valid.
Azure Active Directory validates the access token request
and the MFA claim associated with it, creates an ADRS access
token, and returns it to the application.
B After receiving a ADRS access token, the application detects

if the device has a Windows Hello biometric compatible
sensor. If the application detects a biometric sensor, it gives
the user the choice to enroll biometrics. After completing or
skipping biometric enrollment, the application requires the
user to create a PIN and the default (and fall-back gesture
when used with biometrics). The user provides and confirms
their PIN. Next, the application requests a Windows Hello for
Business key pair from the key pre-generation pool, which
includes attestation data. This is the user key (ukpub/ukpriv).
C The application sends the ADRS token, ukpub, attestation

data, and device information to ADRS for user key
registration. Azure DRS validates the MFA claim remains
current. On successful validation, Azure DRS locates the
user's object in Azure Active Directory, writes the key
information to a multi-values attribute. The key information
includes a reference to the device from which it was created.
Azure Active Directory returns a key ID to the application
which signals the end of user provisioning and the
application exits.
Return to top
Azure AD joined provisioning in a Federated environment

In a federated environment, the plug-in sends the token
request to the on-premises STS, such as Active Directory
Federation Services. The on-premises STS authenticates the
user and determines if the user should perform another
factor of authentication.
The on-premises STS server issues a enterprise token on
successful MFA. The application sends the token to Azure
Active Directory.


registration. Azure DRS validates MFA claim remains current.
On successful validation, Azure DRS locates the user's object
in Azure Active Directory, writes the key information to a
multi-values attribute. The key information includes a
reference to the device from which it was created. Azure
Active Directory returns key ID to the application which
signals the end of user provisioning and the application exits.
Return to top
Hybrid Azure AD joined provisioning in a Key Trust deployment in a

Managed environment



Azure Active Directory returns a key ID to the application
which signals the end of user provisioning and the
application exits.
D Azure AD Connect requests updates on its next

synchronization cycle. Azure Active Directory sends the
user's public key that was securely registered through
provisioning. AAD Connect receives the public key and
writes it to user's msDS-KeyCredentialLink attribute in Active
Directory.
IMPORTANT
The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect
successfully synchronizes the public key to the on-premises Active Directory.
Return to top
Hybrid Azure AD joined provisioning in a synchronous Certificate

Trust deployment in a Federated environment

In a federated environment, the plug-in sends the token
MFA services (or a third party MFA service) provides the
second factor of authentication.
The on-premises STS server issues a enterprise token on
successful MFA. The application sends the token to Azure
Active Directory.


Azure Active Directory returns a key ID and a key receipt to
the application, which represents the end of user key
registration.
D The certificate request portion of provisioning begins after

the application receives a successful response from key
registration. The application creates a PKCS#10 certificate
request. The key used in the certificate request is the same
key that was securely provisioned.
The application sends the key receipt and certificate request,
which includes the public key, to the certificate registration
authority hosted on the Active Directory Federation Services
(AD FS) farm.
After receiving the certificate request, the certificate
registration authority queries Active Directory for the msDS-
KeyCredentialsLink for a list of registered public keys.
E The registration authority validates the public key in the

certificate request matches a registered key for the user.
If the public key in the certificate is not found in the list of
registered public keys, it then validates the key receipt to
confirm the key was securely registered with Azure.
After validating the key receipt or public key, the registration
authority signs the certificate request using its enrollment
agent certificate.
F The registration authority sends the certificate request to

the enterprise issuing certificate authority. The certificate
authority validates the certificate request is signed by a valid
enrollment agent and, on success, issues a certificate and
returns it to the registration authority that then returns the
certificate to the application.
G The application receives the newly issued certificate and

installs the it into the Personal store of the user. This signals
the end of provisioning.
IMPORTANT
Synchronous certificate enrollment does not depend on Azure AD Connect to synchronize the user's public key to issue
the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after
provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not shown
in this flow.
Return to top
Domain joined provisioning in an On-premises Key Trust deployment

token for the Enterprise Device Registration Service (EDRS).
The application makes the request using the Azure Active
In an on-premises deployment, the plug-in sends the token
MFA server (or a third party MFA service) provides the
The on-premises STS server issues a enterprise DRS token
on successful MFA.
B After receiving a EDRS access token, the application detects if

the device has a Windows Hello biometric compatible sensor.
If the application detects a biometric sensor, it gives the user
the choice to enroll biometrics. After completing or skipping
biometric enrollment, the application requires the user to
create a PIN and the default (and fall-back gesture when
used with biometrics). The user provides and confirms their
PIN. Next, the application requests a Windows Hello for
C The application sends the EDRS token, ukpub, attestation

data, and device information to the Enterprise DRS for user
key registration. Enterprise DRS validates the MFA claim
remains current. On successful validation, the Enterprise DRS
locates the user's object in Active Directory, writes the key
The Enterprise DRS returns a key ID to the application, which
represents the end of user key registration.
Return to top
Domain joined provisioning in an On-premises Certificate Trust

deployment

token for the Enterprise Device Registration Service (EDRS).
The application makes the request using the Azure Active
In an on-premises deployment, the plug-in sends the token
MFA server (or a third party MFA service) provides the
The on-premises STS server issues a enterprise DRS token
on successful MFA.
B After receiving a EDRS access token, the application detects if

the device has a Windows Hello biometric compatible sensor.
If the application detects a biometric sensor, it gives the user
the choice to enroll biometrics. After completing or skipping
biometric enrollment, the application requires the user to
create a PIN and the default (and fall-back gesture when
used with biometrics). The user provides and confirms their
PIN. Next, the application requests a Windows Hello for
C The application sends the EDRS token, ukpub, attestation

data, and device information to the Enterprise DRS for user
key registration. Enterprise DRS validates the MFA claim
remains current. On successful validation, the Enterprise DRS
locates the user's object in Active Directory, writes the key
The Enterprise DRS returns a key ID to the application, which
represents the end of user key registration.
D The certificate request portion of provisioning begins after

the application receives a successful response from key
registration. The application creates a PKCS#10 certificate
request. The key used in the certificate request is the same
key that was securely provisioned.
The application sends the certificate request, which includes
the public key, to the certificate registration authority hosted
on the Active Directory Federation Services (AD FS) farm.
After receiving the certificate request, the certificate
registration authority queries Active Directory for the msDS-
KeyCredentialsLink for a list of registered public keys.
E The registration authority validates the public key in the

certificate request matches a registered key for the user.
After validating the public key, the registration authority
signs the certificate request using its enrollment agent
certificate.
F The registration authority sends the certificate request to

the enterprise issuing certificate authority. The certificate
authority validates the certificate request is signed by a valid
enrollment agent and, on success, issues a certificate and
returns it to the registration authority that then returns the
certificate to the application.
G The application receives the newly issued certificate and

installs it into the Personal store of the user. This signals the
end of provisioning.
Return to top
Windows Hello for Business and Authentication
Applies to:
Windows 10
Windows Hello for Business authentication is passwordless, two-factor authentication. Authenticating with
Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure
Active Directory and Active Directory resources.
Azure Active Directory joined devices authenticate to Azure during sign-in and can optional authenticate to
Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in,
and authenticate to Azure Active Directory in the background.
Azure AD join authentication to Azure Active Directory
Azure AD join authentication to Active Directory using a Key
Azure AD join authentication to Active Directory using a Certificate
Hybrid Azure AD join authentication using a Key
Hybrid Azure AD join authentication using a Certificate
Azure AD join authentication to Azure Active Directory
A Authentication begins when the users 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 Azure Active

Directory. Azure AD returns a nonce. The Cloud AP provider
signs the nonce using the user's private key and returns the
signed nonce to the Azure Active Directory.
C Azure Active Directory validates the signed nonce using the

user's securely registered public key against the nonce
signature. After validating the signature, Azure AD then
validates the returned signed nonce. After validating the
nonce, Azure AD 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.
Azure AD join authentication to Active Directory using a Key
A Authentication to Active Directory from a Azure AD 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 2016 domain controller. After the provider
locates an active 2016 domain controller, the provider uses
the private key to sign the Kerberos pre-authentication data.
B The Kerberos provider sends the signed pre-authentication

data and its public key (in the form of a self-signed
certificate) to the Key Distribution Center (KDC) service
running on the 2016 domain controller in the form of a
KERB_AS_REQ.
The 2016 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 pre-authentication 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 has not be 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 is cached and used for subsequent
service ticket requests.
Azure AD join authentication to Active Directory using a Certificate

A Authentication to Active Directory from a Azure AD 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 use the private key to
sign the Kerberos pre-authentication data.

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.
The domain controller determines the certificate is not 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 has not
been revoked. It retrieves the public key and UPN from the
UPN in Active Directory. It validates the signed pre-
authentication 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.

authenticating. After passing this criteria, Kerberos returns
the TGT to lsass, where it is cached and used for subsequent
service ticket requests.
Hybrid Azure AD join authentication using a Key

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.

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 2016 domain controller in the form of a
KERB_AS_REQ.
The 2016 domain controller determines the certificate is a
self-signed certificate. It retrieves the public key from the
public key in Active Directory. It validates the UPN for
authentication request matches the UPN registered in Active
Directory and validates the signed pre-authentication 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.

authenticating.
D After passing this criteria, Kerberos returns the TGT to lsass,

where it is 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 Azure Active
Directory. Azure AD returns a nonce.
G The Cloud AP provider signs the nonce using the user's

private key and returns the signed nonce to the Azure Active
Directory. Azure Active Directory validates the signed nonce
using the user's securely registered public key against the
nonce signature. After validating the signature, Azure AD
then validates the returned signed nonce. After validating
the nonce, Azure AD creates a PRT with session key that is
Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with
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) Azure AD 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.
Hybrid Azure AD join authentication using a Certificate

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.

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.
The domain controller determines the certificate is not 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 has not
been revoked. It retrieves the public key and UPN from the
UPN in Active Directory. It validates the signed pre-
authentication 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.

authenticating.
D After passing this criteria, Kerberos returns the TGT to lsass,

where it is 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 Azure Active
Directory. Azure AD returns a nonce.
G The Cloud AP provider signs the nonce using the user's

private key and returns the signed nonce to the Azure Active
Directory. Azure Active Directory validates the signed nonce
using the user's securely registered public key against the
nonce signature. After validating the signature, Azure AD
then validates the returned signed nonce. After validating
the nonce, Azure AD creates a PRT with session key that is
Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with
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 for the first time.
Windows Hello for Business Deployment Overview
Applies to
Windows 10, version 1703 or later
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.
This deployment overview is to guide you through deploying Windows Hello for Business. Your first step should
be to use the Passwordless Wizard in the Microsoft 365 admin center or the Planning a Windows Hello for
Business Deployment guide to determine the right deployment model for your organization.
Once you've chosen a deployment model, the deployment guide for the that model will provide you with the
information needed to successfully deploy Windows Hello for Business in your environment.
NOTE
Read the Windows Hello for Business Deployment Prerequisite Overview for a summary of the prerequisites for each
different Windows Hello for Business deployment model.
Assumptions
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:
A well-connected, working network
Internet access
Multi-factor Authentication Server to support MFA 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
One or more workstation computers running Windows 10, version 1703
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.
Do not 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

Windows Hello for Business has three deployment models: Cloud, hybrid, and on-premises. Hybrid and on-
premises deployment models have two trust models: Key trust and certificate trust.
Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for
enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure
Active Directory must use the hybrid deployment model for all domains in that forest.
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.
The certificate-trust model is for enterprise 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.
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 Windows Defender Remote Credential Guard.
Following are the various deployment guides and models included in this topic:
Hybrid Azure AD Joined Key Trust Deployment
Hybrid Azure AD Joined Certificate Trust Deployment
Azure AD Join Single Sign-on Deployment Guides
On Premises Key Trust Deployment
On Premises Certificate Trust Deployment
NOTE
For Windows Hello for Business hybrid certificate trust prerequisites and key trust prerequisites deployments, you will
need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active
Directory. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials
are not synchronized to Azure Active Directory. Learn how to deploy Multifactor Authentication Services (MFA) for key
trust and for certificate trust 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 Ser vices Logs\Microsoft\Windows .
NOTE
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.
Planning a Windows Hello for Business Deployment
Applies to
Windows 10
Congratulations! You are 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.
Using this guide

There are many options from which you can choose when deploying Windows Hello for Business. Providing
multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many
options makes the deployment appear complex, however, most organization will realize they've already
implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It is
important to understand that Windows Hello for Business is a distributed system and does take proper planning
across multiple teams within an organization.
This guide removes the appearance of complexity by helping you make decisions on each aspect of your
Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies
the information needed to help you make decisions about the deployment that best suits your environment.
Download the Windows Hello for Business planning worksheet from the Microsoft Download Center to help
track your progress and make your planning easier.
How to Proceed
Read this document and record your decisions on the worksheet. When finished, your worksheet has all the
necessary information for your Windows Hello for Business deployment.
There are six major categories you need to consider for a Windows Hello for Business deployment. Those
categories are:
Deployment Options
Client
Management
Active Directory
Public Key Infrastructure
Cloud
Baseline Prerequisites
Windows Hello for Business has a few baseline prerequisites with which you can begin. These baseline
prerequisites are provided in the worksheet.
Deployment Options
The goal of Windows Hello for Business is to enable deployments for all organizations of any size or scenario. To
provide this type of granular deployment, Windows Hello for Business offers a diverse choice of deployment
options.
Deployment models
There are three deployment models from which you can choose: cloud only, hybrid, and on-premises.
Cl ou d on l y
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.
Hybr i d
The hybrid deployment model is for organizations that:

Are federated with Azure Active Directory
Have identities synchronized to Azure Active Directory using Azure Active Directory Connect
Use applications hosted in Azure Active Directory, and want a single sign-in user experience for both on-
premises and Azure Active Directory resources
IMPORTANT
Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models.
Requirements:
Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement
for this service since version 1903
Reset above lock screen (I forgot my PIN link) - Windows 10, version 1903
O n - p r e m i se s
The on-premises deployment model is for organizations that do not have cloud identities or use applications
hosted in Azure Active Directory.
IMPORTANT
On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust
models.
Requirements:
Reset from settings - Windows 10, version 1703, Professional
Reset above lock screen - Windows 10, version 1709, Professional
It's fundamentally important to understand which deployment model to use for a successful deployment. Some
aspects of the deployment may have already been decided for you based on your current infrastructure.
Trust types
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises
Active Directory. There are two trust types: key trust and certificate trust.
The key trust type does not 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 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). 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 Windows Defender Remote Credential Guard.
Device registration
All devices included in the Windows Hello for Business deployment must go through device registration. Device
registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the
identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-
premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
Key registration
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair
as their user's credentials. The private key is protected by the device's security modules; however, the credential
is a user key (not a device key). The provisioning experience registers the user's public key with the identity
provider. For cloud only and hybrid deployments, the identity provider is Azure Active Directory. For on-
premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active
Directory Federation Services (AD FS) role.
Multifactor authentication
IMPORTANT
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multi-
factor authentication for their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers
who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and
generate activation credentials as usual. See Getting started with the Azure AD Multi-Factor Authentication Server for
more details.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a
strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the
user's weak credentials (username and password) as the first factor authentication; however, the user must
provide a second factor of authentication before Windows provisions a strong credential.
Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises
deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in
conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-
premises Azure AD Multi-Factor Authentication server, or choose from several third parties (Read Microsoft and
third-party additional authentication methods for more information).
NOTE
Azure AD Multi-Factor Authentication is available through:
Microsoft Enterprise Agreement
Open Volume License Program
Cloud Solution Providers program
Bundled with
Azure Active Directory Premium
Enterprise Mobility Suite
Enterprise Cloud Suite
Directory synchronization
Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose.
Hybrid deployments use Azure Active Directory Connect to synchronize Active Directory identities or credentials
between itself and Azure Active Directory. This helps enable single sign-on to Azure Active Directory and its
federated components. On-premises deployments use directory synchronization to import users from Active
Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
Management
Windows Hello for Business provides organizations with a rich set of granular policy settings with which they
can use to manage their devices and users. There are three ways in which you can manage Windows Hello for
Business: Group Policy, Modern Management, and Mixed.
Group Policy
Group Policy is the easiest and most popular way to manage Windows Hello for Business on domain joined
devices. Simply create a Group Policy object with the settings you desire. Link the Group Policy object high in
your Active Directory and use security group filtering to target specific sets of computers or users. Or, link the
GPO directly to the organizational units.
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
Client
Windows Hello for Business is an exclusive Windows 10 feature. As part of the Windows as a Service strategy,
Microsoft has improved the deployment, management, and user experience with each new release of Windows
10 and introduced support for new scenarios.
Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November
Update. The client requirement may change based on different components in your existing infrastructure, or
other infrastructure choices made later in planning your deployment. Those components and choices may
require a minimum client running Windows 10, version 1703, also known as the Creators Update.
Active Directory
Hybrid and on-premises deployments include Active Directory as part of their infrastructure. Most of the Active
Directory requirements, such as schema, and domain and forest functional levels are predetermined. However,
your trust type choice for authentication determines the version of domain controller needed for the
deployment.
The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust
anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in
order for Windows 10 devices to trust the domain controller as legitimate. Deployments using the certificate
trust type need an enterprise public key infrastructure and a certificate registration authority to issue
authentication certificates to users. Hybrid deployments may need to issue VPN certificates to users to enable
connectivity on-premises resources.
Cloud
Some deployment combinations require an Azure account, and some require Azure Active Directory for user
identities. These cloud requirements may only need an Azure account while other features need an Azure Active
Directory Premium subscription. The planning process identifies and differentiates the components that are
needed from those that are optional.
Planning a Deployment
Planning your Windows Hello for Business deployment begins with choosing a deployment type. Like all
distributed systems, Windows Hello for Business depends on multiple components within your organization's
infrastructure.
Use the remainder of this guide to help with planning your deployment. As you make decisions, write the results
of those decisions in your planning worksheet. When finished, you'll have all the information needed to
complete the planning process and the appropriate deployment guide that best helps you with your
deployment.
Deployment Model
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 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.
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.
Trust type
Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue
certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible
MDM need the Windows Server NDES server role to issue certificates.
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 (Windows Server 2008R2 or later) 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 Azure AD Connect.
If your organization wants to use the key trust type, write key trust in box 1b on your planning worksheet.
Write Windows Ser ver 2016 in box 4d . Write N/A in box 5b .
If your organization wants to use the certificate trust type, write cer tificate trust in box 1b on your planning
worksheet. Write Windows Ser ver 2008 R2 or later in box 4d . In box 5c , write smar t card logon under
the Template Name column and write users under the Issued To column on your planning worksheet.
Device Registration
A successful Windows Hello for Business requires all devices to register with the identity provider. The identity
provider depends on the deployment model.
If box 1a on your planning worksheet reads cloud only or hybrid , write Azure in box 1c on your planning
worksheet.
If box 1a on your planning worksheet reads on-premises , write AD FS in box 1c on your planning worksheet.
Key Registration
All users provisioning Windows Hello for Business have their public key registered with the identity provider.
The identity provider depends on the deployment model.
If box 1a on your planning worksheet reads cloud only or hybrid , write Azure in box 1d on your planning
worksheet.
If box 1a on your planning worksheet reads on-premises , write AD FS in box 1d on your planning worksheet.
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 multi-factor 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 Azure Active Directory and there is not another directory with which the information must be
synchronized.
If box 1a on your planning worksheet reads hybrid , then write Azure AD Connect in box 1e on your planning
worksheet.
If box 1a on your planning worksheet reads on-premises , then write Azure MFA Ser ver . This deployment
exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The
on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide
multi-factor authentication while the user's credentials remain on the on-premises network.
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 multi-factor 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.
If box 1a on your planning worksheet reads hybrid , then you have a few options, some of which depend on
your directory synchronization configuration. The options from which you may choose include:
Directly use Azure MFA cloud service
Use AD FS w/Azure MFA cloud service adapter
Use AD FS w/Azure MFA Server adapter
Use AD FS w/3rd Party MFA Adapter
You can directly use the Azure MFA cloud service for the second factor of authentication. Users contacting the
service must authenticate to Azure prior to using the service.
If your Azure AD Connect is configured to synchronize identities (usernames only), then your users are
redirected to your local on-premises federation server for authentication and then redirected back to the Azure
MFA cloud service. Otherwise, your Azure AD Connect is configured to synchronize credentials (username and
passwords), which enables your users to authenticate to Azure Active Directory and use the Azure MFA cloud
service. If you choose to use the Azure MFA cloud service directly, write Azure MFA in box 1f on your planning
worksheet.
You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In
this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD
FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of
authentication. If you choose to use AD FS with the Azure MFA cloud service adapter, write AD FS with Azure
MFA cloud adapter in box 1f on your planning worksheet.
Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. Rather than AD FS
communicating directly with the Azure MFA cloud service, it communicates with an on-premises Azure MFA
server that synchronizes user information with the on-premises Active Directory. The Azure MFA server
communicates with Azure MFA cloud services to perform the second factor of authentication. If you choose to
use AD FS with the Azure MFA server adapter, write AD FS with Azure MFA ser ver adapter in box 1f on
your planning worksheet.
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 par ty 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 you choose to use AD FS with the Azure MFA server adapter, write AD FS with Azure MFA ser ver 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 par ty in box 1f on your planning worksheet.
Management
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 Azure Active Directory joined
devices, write modern management in box 2b on your planning worksheet. Otherwise, write** N/A** in box
2b .
NOTE
Azure Active Directory 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-
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 modern management for both domain and non-domain 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. 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-
NOTE
Azure Active Directory 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.
Box 1a on your planning worksheet reads hybrid , box 1b reads key 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.
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 cer tificate 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.
Active Directory
The Active Directory portion of the planning guide should be complete. Most of the conditions are baseline
prerequisites except for your domain controllers. The domain controllers used in your deployment are decided
by the chosen trust type.
Review the trust type portion of this section if box 4d on your planning worksheet remains empty.
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 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. Hybrid Azure AD joined devices managed by Group Policy need the Windows
Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD 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:
C ERT IF IC AT E T EM P L AT E N A M E ISSUED TO
Exchange Enrollment Agent AD FS RA
Web Server AD FS RA
Exchange Enrollment Agent NDES
Web Server NDES
CEP Encryption NDES
If box 2a reads GP and box 2b reads N/A , write AD FS RA in box 5b and write the following certificate
template names and issuances in box 5c on your planning worksheet.
Exchange Enrollment Agent AD FS RA
Web Server AD FS RA
If box 2a or 2b reads modern management, write NDES in box 5b and write the following certificate template
names and issuances in box 5c on your planning worksheet.
Exchange Enrollment Agent NDES
Web Server NDES

CEP Encryption NDES
Cloud
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 par ty , 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.
Windows Hello for Business does not require an Azure AD premium subscription. However, some dependencies,
such as MDM automatic enrollment and Conditional Access do.
If box 1a on your planning worksheet reads on-premises , write No in box 6c on your planning worksheet.
If box 1a on your planning worksheet reads hybrid and box 1b reads key trust , write No in box 6c on your
planning worksheet. You can deploy Windows Hello for Business using the Azure Active Directory free tier. All
Azure Active Directory free accounts can use Azure AD Multi-Factor Authentication through the use of security
defaults. Some Azure AD Multi-Factor Authentication features require a license. For more details, see Features
and licenses for Azure AD Multi-Factor Authentication.
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, an Azure AD Premium feature.
Modern managed devices do not require an Azure AD premium 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 .
Congratulations, You're Done

Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding
of the components used in the Windows Hello for Business infrastructure and rationalization of why they are
used. The worksheet gives you an overview of the requirements needed to continue the next phase of the
deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business
deployment.
Windows Hello for Business Deployment
Prerequisite Overview
This article lists the infrastructure requirements for the different deployment models for Windows Hello for
Business.
Cloud Only Deployment

Microsoft Azure Account
Azure Active Directory
Azure AD Multi-Factor Authentication
Modern Management (Intune or supported third-party MDM), optional
Azure AD Premium subscription - optional, needed for automatic MDM enrollment when the device joins
Hybrid Deployments
The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest
deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for
business components or is involved in the Kerberos referral process.
K EY T RUST C ERT IF IC AT E T RUST K EY T RUST C ERT IF IC AT E T RUST

GRO UP P O L IC Y M A N A GED M IXED M A N A GED M O DERN M A N A GED M O DERN M A N A GED
Windows 10, version 1511 Hybrid Azure AD Joined: Windows 10, version 1511 Windows 10, version 1511
or later Minimum: Windows 10, or later or later
version 1703
Best experience: Windows
10, version 1709 or later
(supports synchronous
certificate enrollment).
Azure AD Joined:
Windows 10, version 1511
or later
Windows Server 2016 or Windows Server 2016 or Windows Server 2016 or Windows Server 2016 or
later Schema later Schema later Schema later Schema
Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2
Domain/Forest functional Domain/Forest functional Domain/Forest functional Domain/Forest functional
level level level level
Windows Server 2016 or Windows Server 2008 R2 or Windows Server 2016 or Windows Server 2008 R2 or
later Domain Controllers later Domain Controllers later Domain Controllers later Domain Controllers
Windows Server 2012 or Windows Server 2012 or Windows Server 2012 or Windows Server 2012 or
later Certificate Authority later Certificate Authority later Certificate Authority later Certificate Authority
K EY T RUST C ERT IF IC AT E T RUST K EY T RUST C ERT IF IC AT E T RUST
GRO UP P O L IC Y M A N A GED M IXED M A N A GED M O DERN M A N A GED M O DERN M A N A GED
N/A Windows Server 2016 AD N/A Windows Server 2012 or

FS with KB4088889 update later Network Device
(hybrid Azure AD joined Enrollment Service
clients),
and
Windows Server 2012 or
later Network Device
Enrollment Service (Azure
AD joined)
Azure MFA tenant, or Azure MFA tenant, or Azure MFA tenant, or Azure MFA tenant, or
AD FS w/Azure MFA AD FS w/Azure MFA AD FS w/Azure MFA AD FS w/Azure MFA
adapter, or adapter, or adapter, or adapter, or
AD FS w/Azure MFA Server AD FS w/Azure MFA Server AD FS w/Azure MFA Server AD FS w/Azure MFA Server
adapter, or adapter, or adapter, or adapter, or
AD FS w/3rd Party MFA AD FS w/3rd Party MFA AD FS w/3rd Party MFA AD FS w/3rd Party MFA
Adapter Adapter Adapter Adapter
Azure Account Azure Account Azure Account Azure Account
Azure Active Directory Azure Active Directory Azure Active Directory Azure Active Directory
Azure AD Connect Azure AD Connect Azure AD Connect Azure AD Connect
Azure AD Premium, Azure AD Premium, needed Azure AD Premium, Azure AD Premium,

optional for device write-back optional for automatic optional for automatic
MDM enrollment MDM enrollment
IMPORTANT
1. Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust
models.
Requirements:
Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing
requirement for this service since version 1903
2. On-premises deployments support destructive PIN reset that works with both the certificate trust and the key
trust models.
Requirements:
Reset above lock screen - Windows 10, version 1709, Professional
On-premises Deployments
The table shows the minimum requirements for each deployment.
K EY T RUST C ERT IF IC AT E T RUST

GRO UP P O L IC Y M A N A GED GRO UP P O L IC Y M A N A GED
Windows 10, version 1703 or later Windows 10, version 1703 or later
K EY T RUST C ERT IF IC AT E T RUST
GRO UP P O L IC Y M A N A GED GRO UP P O L IC Y M A N A GED
Windows Server 2016 Schema Windows Server 2016 Schema
Windows Server 2008 R2 Domain/Forest functional level Windows Server 2008 R2 Domain/Forest functional level
Windows Server 2016 or later Domain Controllers Windows Server 2008 R2 or later Domain Controllers
Windows Server 2012 or later Certificate Authority Windows Server 2012 or later Certificate Authority
Windows Server 2016 AD FS with KB4088889 update Windows Server 2016 AD FS with KB4088889 update
AD FS with 3rd Party MFA Adapter AD FS with 3rd Party MFA Adapter
Azure Account, optional for Azure MFA billing Azure Account, optional for Azure MFA billing
IMPORTANT
For Windows Hello for Business key trust deployments, if you have several domains, at least one Windows Server Domain
Controller 2016 or newer is required for each domain. For more information, see the planning guide.
Applies to
Windows 10
When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people
in your organization by explaining how to use Hello.
After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate
resources. Their gesture is only valid on the enrolled device.
Although the organization may require users to change their Active Directory or Azure Active Directory (AD)
account password at regular intervals, changes to their passwords have no effect on Hello.
People who are currently using virtual or physical smart cards for authentication can use their virtual smart card
to verify their identity when they set up Hello.
On devices owned by the organization

When someone sets up a new device, they are prompted to choose who owns the device. For corporate devices,
they select This device belongs to my organization .
Next, they select a way to connect. Tell the people in your enterprise which option they should pick here.
They sign in, and are then asked to verify their identity. People have options to choose from a text message,
phone call, or the authentication application. After verification, they create their PIN. The Create a PIN screen
displays any complexity requirements that you have set, such as minimum length.
After Hello is set up, people use their PIN to unlock the device, and that will automatically log them on.
On personal devices
People who want to access work resources on their personal devices can add a work or school account in
Settings > Accounts > Work or school , and then sign in with work credentials. The person selects the
method for receiving the verification code, such as text message or email. The verification code is sent and the
person then enters the verification code. After verification, the person enters and confirms new PIN. The person
can access any token-based resource using this device without being asked for credentials.
People can go to Settings > Accounts > Work or school , select the work account, and then select Unjoin to
remove the account from their device.
Using Windows Hello and biometrics

If your policy allows it, people can use biometrics (fingerprint, iris, and facial recognition) with Windows Hello
for Business, if the hardware supports it.
Related topics
Hybrid Azure AD joined Key Trust Deployment
Applies to
Hybrid deployment
Key trust
Windows Hello for Business replaces username and password sign-in to Windows with strong user
authentication based on asymmetric key pair. The following deployment guide provides the information needed
to successfully deploy Windows Hello for Business in a hybrid key trust scenario.
It is recommended that you review the Windows Hello for Business planning guide prior to using the
deployment guide. The planning guide helps you make decisions by explaining the available options with each
aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review
the planning guide and download the planning worksheet.
This deployment guide provides guidance for new deployments and customers who are already federated with
Office 365. These two scenarios provide a baseline from which you can begin your deployment.
New Deployment Baseline

The new deployment baseline helps organizations who are moving to Azure and Office 365 to include Windows
Hello for Business as part of their deployments. This baseline is good for organizations who are looking to
deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for
Business by deploying a lab environment.
This baseline provides detailed procedures to move your environment from an on-premises only environment
to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your
on-premises Active Directory using a single Windows sign-in.
Your next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the
prerequisites will be new for organizations and individuals pursuing the new deployment baseline.
Organizations and individuals starting from the federated baseline will likely be familiar with most of the
prerequisites, but should validate they are using the proper versions that include the latest updates.
Prerequisites
Follow the Windows Hello for Business hybrid key trust deployment
guide
1. Overview (You are here)
2. Prerequisites
3. New Installation Baseline
4. Configure Directory Synchronization
5. Configure Azure Device Registration
6. Configure Windows Hello for Business settings
7. Sign-in and Provision
Hybrid Key trust Windows Hello for Business
Prerequisites
Applies to
Hybrid deployment
Key trust
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based
identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on
which organizations can provide two-factor authentication that provides a single sign-in like experience to
modern resources.
The distributed systems on which these technologies were built involved several pieces of on-premises and
cloud infrastructure. High-level pieces of the infrastructure include:
Directories
Federation
MultiFactor Authentication
Device Registration
Directories
Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure
Active Directory. The minimum required domain functional and forest functional levels for Windows Hello for
Business deployment is Windows Server 2008 R2.
A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. The hybrid key
trust deployment, does not need a premium Azure Active Directory subscription.
You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain
controllers.
If using the key trust deployment model, you MUST ensure that you have adequate (1 or more, depending on
your authentication load) Windows Server 2016 or later Domain Controllers in each Active Directory site where
users will be authenticating for Windows Hello for Business.
Read the Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows
Hello for Business deployments to learn more.
NOTE
There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server
2019 domain controllers refer to KB4487044 to fix this issue.
Review these requirements and those from the Windows Hello for Business planning guide and worksheet.
Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your
Azure Active Directory subscription to meet your needs.
Section Review
Active Directory Domain Functional Level
Active Directory Forest Functional Level
Domain Controller version
Azure Active Directory subscription
Correct subscription for desired features and outcomes

The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor
for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows 10
devices to trust the domain controller.
Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory
user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the
public key of the registered Windows Hello for Business credential to an attribute on the user's Active Directory
object.
The minimum required Enterprise certificate authority that can be used with Windows Hello for Business is
Windows Server 2012, but you can also use a third-party Enterprise certification authority. The requirements for
the domain controller certificate are shown below. For more details, see Requirements for domain controller
certificates from a third-party CA.
The certificate must have a Certificate Revocation List (CRL) distribution point extension that points to a valid
CRL, or an Authority Information Access (AIA) extension that points to an Online Certificate Status Protocol
(OCSP) responder.
The certificate Subject section should contain the directory path of the server object (the distinguished
name).
The certificate Key Usage section must contain Digital Signature and Key Encipherment.
Optionally, the certificate Basic Constraints section should contain: [Subject Type=End Entity, Path Length
Constraint=None].
The certificate Enhanced Key Usage section must contain Client Authentication (1.3.6.1.5.5.7.3.2), Server
Authentication (1.3.6.1.5.5.7.3.1), and KDC Authentication (1.3.6.1.5.2.3.5).
The certificate Subject Alternative Name section must contain the Domain Name System (DNS) name.
The certificate template must have an extension that has the value "DomainController", encoded as a
BMPstring. If you are using Windows Server Enterprise Certificate Authority, this extension is already
included in the domain controller certificate template.
The domain controller certificate must be installed in the local computer's certificate store. See Configure
Hybrid Windows Hello for Business: Public Key Infrastructure for details.
IMPORTANT
For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based
url.
Section Review
Windows Server 2012 Issuing Certificate Authority
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect
to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync need to
upgrade to Azure AD Connect.
Section Review
Azure Active Directory Connect directory synchronization
Upgrade from DirSync
Upgrade from Azure AD Sync
Federation with Azure

You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-
federated environments, key trust deployments work in environments that have deployed Password
Synchronization with Azure AD Connect or Azure Active Directory Pass-through-Authentication. For federated
environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services
(AD FS) 2012 R2 or later.
Non-federated environments
Federated environments
Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency
on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their user name
and password as one factor, but needs a second factor of authentication.
Hybrid Windows Hello for Business deployments can use Azure's Multifactor Authentication (MFA) service or
they can use multifactor authentication provided by AD FS beginning with Windows Server 2012 R2, which
includes an adapter model that enables third parties to integrate their MFA into AD FS. The MFA enabled by an
Office 365 license is sufficient for Azure AD.
Section Review
Azure MFA Service
Windows Server 2016 AD FS and Azure (optional, if federated)
Windows Server 2016 AD FS and third party MFA Adapter (optional, if federated)
Device Registration
Organizations wanting to deploy hybrid key trust need their domain joined devices to register to Azure Active
Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud.
This ensures that only approved computers are used with that Azure Active Directory. Each computer registers
its identity in Azure Active Directory.
Provisioning
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.
Section Checklist
Device Registration with Azure Device Registration
Next Steps
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new
installations, choose the New Installation Baseline .
For environments transitioning from on-premises to hybrid, start with Configure Azure Director y
Synchronization .
For federated and non-federated environments, start with Configure Windows Hello for Business settings .
guide
1. Overview
2. Prerequisites (You are here)
Windows Hello for Business Key Trust New
Installation
Applies to
Hybrid deployment
Key trust
Windows Hello for Business involves configuring distributed technologies that may or may not exist in your
current infrastructure. Hybrid key trust deployments of Windows Hello for Business rely on these technologies
Active Directory
Multifactor Authentication Services
New installations are considerably more involved than existing implementations because you are building the
entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing
environment has all the needed configurations to support your hybrid certificate trust Windows Hello for
Business deployment. If your environment meets these needs, you can read the Configure Directory
Synchronization section to prepare your Windows Hello for Business deployment by configuring directory
synchronization.
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.
Active Directory
This document expects you have Active Directory deployed with an adequate number of Windows Server 2016
or later domain controllers for each site. Read the Planning an adequate number of Windows Server 2016
Domain Controllers for Windows Hello for Business deployments to learn more.
NOTE
Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The
purpose of these environments is to experiment and learn. Reducing the number of domain controllers can
prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
Section Review
An adequate number of Windows Server 2016 domain controllers
Minimum Windows Server 2008 R2 domain and forest functional level
Functional networking, name resolution, and Active Directory replication

Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model.
All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust
for clients to ensure they are not communicating with a rogue domain controller.
This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business
depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services
role from Windows Server 2012 or later.
Lab-based public key infrastructure
The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab
environment.
Sign-in using Enterprise Admin equivalent credentials on Windows Server 2012 or later server where you want
the certificate authority installed.
NOTE
Never install a certificate authority on a domain controller in a production environment.
1. Open an elevated Windows PowerShell prompt.

2. Use the following command to install the Active Directory Certificate Services role.
add-windowsfeature adcs-cert-authority -IncludeManagementTools
3. Use the following command to configure the Certificate Authority using a basic certificate authority
configuration.
Install-AdcsCertificationAuthority
Configure a Production Public Key Infrastructure

If you do not have an existing public key infrastructure, please review Certification Authority Guidance from
Microsoft TechNet to properly design your infrastructure. Then, consult the Test Lab Guide: Deploying an AD CS
Two-Tier PKI Hierarchy for instructions on how to configure your public key infrastructure using the information
from your design session.
IMPORTANT
For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based
URL.
Section Review
Minimum Windows Server 2012 Certificate Authority.
Enterprise Certificate Authority.
Functioning public key infrastructure.
Root certificate authority certificate (Azure AD Joined devices).
Highly available certificate revocation list (Azure AD Joined devices).
You've prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active
Directory to host your cloud-based identities.
The next step of the deployment is to follow the Creating an Azure AD tenant process to provision an Azure
tenant for your organization.
Section Review
Review the different ways to establish an Azure Active Directory tenant.
Create an Azure Active Directory Tenant.
Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.

Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN
reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication
configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA or a third-party MFA adapter
Review the What is Azure AD Multi-Factor Authentication topic to familiarize yourself its purpose and how it
works.
Azure AD Multi-Factor Authentication (MFA ) Cloud
IMPORTANT
As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to
do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that
enable Azure MFA are:
Enterprise Mobility + Security
If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section.
Configure Azure MFA Settings

Review the Configure Azure AD Multi-Factor Authentication settings section to configure your settings.
Azure MFA User States
After you have completed configuring your Azure MFA settings, you want to review How to require two-step
verification for a user to understand user states. User states determine how you enable Azure MFA for your
users.
Azure MFA via ADFS
Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide
additional multi-factor authentication. To configure, read the Configure AD FS 2016 and Azure MFA section.
Section Review
Review the overview and uses of Azure AD Multi-Factor Authentication.
Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication.
Create an Azure AD Multi-Factor Authentication Provider, if necessary.
Configure Azure AD Multi-Factor Authentication features and settings.
Understand the different User States and their effect on Azure AD Multi-Factor Authentication.
Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider
with Windows Server Active Directory Federation Services, if necessary.
guide
1. Overview
2. Prerequisites
3. New Installation Baseline (You are here)
Configure Directory Synchronization for Hybrid key
trust Windows Hello for Business
Applies to
Hybrid deployment
Key trust
You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for
Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in
the cloud or on-premises.
Deploy Azure AD Connect

Next, you need to synchronize the on-premises Active Directory with Azure Active Directory. To do this, first
review the Integrating on-prem directories with Azure Active Directory and hardware and prerequisites needed
and then download the software.
NOTE
If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect
installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is
configured.
guide
1. Overview
2. Prerequisites
4. Configure Directory Synchronization (You are here)
Configure Device Registration for Hybrid key trust
Applies to
Hybrid deployment
Key trust
You are ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business
deployment needs device registration to enable proper device authentication.
NOTE
Before proceeding, you should familiarize yourself with device registration concepts such as:
Azure AD registered devices
Azure AD joined devices
Hybrid Azure AD joined devices
You can learn about this and more by reading Introduction to Device Management in Azure Active Directory.
Configure Azure for Device Registration

Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device
registration capabilities in Azure AD.
To do this, follow the Configure device settings steps under Setting up Azure AD Join in your organization.
Next, follow the guidance on the How to configure hybrid Azure Active Directory joined devices page. In the
Configuration steps section, identify your configuration at the top of the table (either Windows current and
password hash sync or Windows current and federation ) and perform only the steps identified with a
check mark.
guide
1. Overview
2. Prerequisites
5. Configure Azure Device Registration (You are here)
Configure Hybrid Windows Hello for Business key
trust settings
Applies to
Hybrid deployment
Key trust
You are ready to configure your hybrid key trust environment for Windows Hello for Business.
IMPORTANT
Ensure your environment meets all the prerequisites before proceeding. Review the New Installation baseline section of
this deployment document to learn how to prepare your environment for your Windows Hello for Business deployment.
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
Active Directory
Azure AD Connect
Group Policy
For the most efficient deployment, configure these technologies in order beginning with the Active Directory
configuration
C O N F I G U R E A C T I V E D I R E C TO R Y
>
guide
1. Overview
2. Prerequisites
6. Configure Windows Hello for Business settings (You are here)
Hybrid Windows Hello for Business Provisioning
Applies to
Hybrid deployment
Key trust
Provisioning
The 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
The first thing to validate is the computer has processed device registration. You can view this from the User
device registration logs where the check Device is AAD joined (AADJ or DJ++): Yes appears. Additionally,
you can validate this using the dsregcmd /status command from a console prompt where the value for
AzureADJoined reads Yes .
Windows Hello for Business provisioning begins with a full screen page with the title Setup a PIN and button
with the same name. The user clicks Setup a PIN .
The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning
informs the user that it is actively attempting to contact the user through their configured form of MFA. The
provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA
results in an error and asks the user to retry.
After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe
any PIN complexity requirements that you deployed to the environment.
The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
A successful single factor authentication (username and password at sign-in)
A device that has successfully completed device registration
A fresh, successful multi-factor authentication
A validated PIN that meets the PIN complexity requirements
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for
the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired,
Windows communicates with Azure Active Directory to register the public key. When key registration completes,
Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close
the provisioning application and see their desktop. While the user has completed provisioning, Azure AD
Connect synchronizes the user's key to Active Directory.
IMPORTANT
The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active
Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. This synchronization
latency delays the user's ability to authenticate and use on-premises resources until the user's public key
has synchronized to Active Director y. Once synchronized, the user can authenticate and use on-premises resources.
Read Azure AD Connect sync: Scheduler to view and adjust the synchronization cycle for your organization.
guide
1. Overview
2. Prerequisites
7. Sign-in and Provision(You are here)
Hybrid Azure AD joined Certificate Trust
Deployment
Applies to
Hybrid deployment
Certificate trust
to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario.
It is recommended that you review the Windows Hello for Business planning guide prior to using the
deployment guide. The planning guide helps you make decisions by explaining the available options with each
aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review
the planning guide and download the planning worksheet.
This deployment guide provides guidance for new deployments and customers who are already federated with
Office 365. These two scenarios provide a baseline from which you can begin your deployment.
New Deployment Baseline

The new deployment baseline helps organizations who are moving to Azure and Office 365 to include Windows
Hello for Business as part of their deployments. This baseline is good for organizations who are looking to
deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for
Business by deploying a lab environment.
This baseline provides detailed procedures to move your environment from an on-premises only environment
to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your
on-premises Active Directory using a single Windows sign-in.
Federated Baseline
The federated baseline helps organizations that have completed their federation with Azure Active Directory and
Office 365 and enables them to introduce Windows Hello for Business into their hybrid environment. This
baseline exclusively focuses on the procedures needed to add Azure Device Registration and Windows Hello for
Business to an existing hybrid deployment.
Regardless of the baseline you choose, your next step is to familiarize yourself with the prerequisites needed for
the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new
deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar
with most of the prerequisites, but should validate they are using the proper versions that include the latest
updates.
Prerequisites
Follow the Windows Hello for Business hybrid certificate trust
deployment guide
1. Overview (You are here)
2. Prerequisites
4. Device Registration
Hybrid Windows Hello for Business Prerequisites
Applies to
Hybrid deployment
Certificate trust
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based
identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on
which organizations can provide two-factor authentication that provides a single sign-in like experience to
modern resources.
The distributed systems on which these technologies were built involved several pieces of on-premises and
cloud infrastructure. High-level pieces of the infrastructure include:
Directories
Federation
Device Registration
Directories
Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure
Active Directory. The minimum required domain controller, domain functional level, and forest functional level
for Windows Hello for Business deployment is Windows Server 2008 R2.
A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. Different
deployment configurations are supported by different Azure subscriptions. The hybrid-certificate trust
deployment needs an Azure Active Directory premium subscription because it uses the device write-back
synchronization feature. Other deployments, such as the hybrid key-trust deployment, may not require Azure
Active Directory premium subscription.
Windows Hello for Business can be deployed in any environment with Windows Server 2008 R2 or later
domain controllers. Azure device registration and Windows Hello for Business require the Windows Server
2016 Active Directory or later schema.
Review these requirements and those from the Windows Hello for Business planning guide and worksheet.
Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your
Azure Active Directory subscription to meet your needs.
Section Review
Active Directory Domain Functional Level
Active Directory Forest Functional Level
Domain Controller version
Windows Server 2016 or later Schema
Azure Active Directory subscription
Correct subscription for desired features and outcomes

The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor
for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows 10
devices to trust the domain controller.
Certificate trust deployments need an enterprise public key infrastructure and a certificate registration authority
to issue authentication certificates to users. When using Group Policy, hybrid certificate trust deployment uses
the Windows Server 2016 Active Directory Federation Server (AD FS) as a certificate registration authority.
The minimum required enterprise certificate authority that can be used with Windows Hello for Business is
Windows Server 2012.
Section Review
Windows Server 2012 Issuing Certificate Authority
Windows Server 2016 Active Directory Federation Services
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect
to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to
upgrade to Azure AD Connect. In case the schema of your local AD DS was changed since the last directory
synchronization, you may need to refresh directory schema.
NOTE
Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized
between Azure Active Directory and Active Directory.
Section Review
Azure Active Directory Connect directory synchronization
Upgrade from DirSync
Upgrade from Azure AD Sync
Federation
Windows Hello for Business hybrid certificate trust requires Active Directory being federated with Azure Active
Directory and needs Windows Server 2016 Active Directory Federation Services or newer. Windows Hello for
Business hybrid certificate trust doesn’t support Managed Azure Active Directory using Pass-through
authentication or password hash sync. All nodes in the AD FS farm must run the same version of AD FS.
Additionally, you need to configure your AD FS farm to support Azure registered devices.
The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of
KB4088889 (14393.2155). If your AD FS farm is not running the AD FS role with updates from Windows Server
2016, then read Upgrading to AD FS in Windows Server 2016
Section Review
Windows Server 2016 Active Directory Federation Services
Minimum update of KB4088889 (14393.2155)
Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency
on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their username
and password as one factor. but needs a second factor of authentication.
Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service, or they can
use multifactor authentication provides by Windows Server 2016 Active Directory Federation Services, which
includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
Section Review
Azure MFA Service
Windows Server 2016 AD FS and Azure
Windows Server 2016 AD FS and third party MFA Adapter
Device Registration
Organizations wanting to deploy hybrid certificate trust need their domain joined devices to register to Azure
Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in
the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer
registers its identity in Azure Active Directory.
Hybrid certificate trust deployments need the device write back feature. Authentication to the Windows Server
2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the
users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in
Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business
deployments need device writeback, which is an Azure Active Directory premium feature.
NOTE
Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized
between Azure Active Directory and Active Directory, and therefore the device writeback is used to update the msDS-
KeyCredentialLink on the computer object.
Provisioning
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.
Section Checklist
Azure Active Directory Device writeback
Azure Active Directory Premium subscription
Next Steps
Follow the Windows Hello for Business hybrid certificate trust deployment guide. For proof-of-concepts, labs,
and new installations, choose the New Installation Baseline .
If your environment is already federated, but does not include Azure device registration, choose Configure
Azure Device Registration .
If your environment is already federated and supports Azure device registration, choose Configure Windows
Hello for Business settings .

deployment guide
1. Overview
2. Prerequisites (You are here)
Windows Hello for Business Certificate Trust New
Installation
Applies to
Hybrid deployment
Certificate trust
Windows Hello for Business involves configuring distributed technologies that may or may not exist in your
current infrastructure. Hybrid certificate trust deployments of Windows Hello for Business rely on these
technologies
Active Directory
New installations are considerably more involved than existing implementations because you are building the
entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing
environment has all the needed configurations to support your hybrid certificate trust Windows Hello for
Business deployment. If your environment meets these needs, you can read the Configure Azure Device
Registration section to prepare your Windows Hello for Business deployment by configuring Azure device
registration.
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI. This document
expects you have Active Directory deployed using Windows Server 2008 R2 or later domain controllers.
Active Directory
Production environments should follow Active Directory best practices regarding the number and placement of
domain controllers to ensure adequate authentication throughout the organization.
Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The
purpose of these environments is to experiment and learn. Reducing the number of domain controllers can
prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
Section Review
Minimum Windows Server 2008 R2 domain controllers
Minimum Windows Server 2008 R2 domain and forest functional level
Functional networking, name resolution, and Active Directory replication

for clients to ensure they are not communicating with a rogue domain controller. The certificate trust model
extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user
receives a sign-in certificate.
This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business
environment.
NOTE

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
configuration.

If you do have an existing public key infrastructure, please review Certification Authority Guidance from
Section Review
Minimum Windows Server 2012 Certificate Authority.
Enterprise Certificate Authority.
Functioning public key infrastructure.

You’ve prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active
Directory to host your cloud-based identities.
The next step of the deployment is to follow the Creating an Azure AD tenant process to provision an Azure
tenant for your organization.
Section Review
Review the different ways to establish an Azure Active Directory tenant.
Create an Azure Active Directory Tenant.
Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.

Windows Hello for Business uses multi-factor authentication during provisioning and during user initiated PIN
reset scenarios, such as when a user forgets their PIN. There are two preferred multi-factor authentication
configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
Review the What is Azure AD Multi-Factor Authentication topic to familiarize yourself its purpose and how it
works.
Azure AD Multi-Factor Authentication (MFA ) Cloud
IMPORTANT
As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to
do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that
enable Azure MFA are:
Enterprise Mobility + Security
If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section.
Azure MFA Provider

If your organization uses Azure MFA on a per-consumption model (no licenses), then review the Create a
Multifactor Authentication Provider section to create an Azure MFA Authentication provider and associate it with
your Azure tenant.
Configure Azure MFA Settings
Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you
need to configure the multi-factor authentication settings. Review the Configure Azure AD Multi-Factor
Authentication settings section to configure your settings.
Azure MFA User States
After you have completed configuring your Azure MFA settings, you want to review configure User States to
understand user states. User states determine how you enable Azure MFA for your users.
Azure MFA via ADFS 2016
Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide
additional multi-factor authentication. To configure, read the Configure AD FS 2016 and Azure MFA section
Section Review
Review the overview and uses of Azure AD Multi-Factor Authentication Authentication.
Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication.
Create an Azure AD Multi-Factor Authentication Provider, if necessary.
Configure Azure AD Multi-Factor Authentication features and settings.
Understand the different User States and their effect on Azure AD Multi-Factor Authentication.
Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider
with Windows Server 2016 Active Directory Federation Services, if necessary.

deployment guide
1. Overview
2. Prerequisites
3. New Installation Baseline (You are here)
Configure Device Registration for Hybrid Windows
Hello for Business
Applies to
Hybrid deployment
Certificate trust
Your environment is federated and you are ready to configure device registration for your hybrid environment.
Hybrid Windows Hello for Business deployment needs device registration and device write-back to enable
proper device authentication.
IMPORTANT
If your environment is not federated, review the New Installation baseline section of this deployment document to learn
how to federate your environment for your Windows Hello for Business deployment.
TIP
Refer to the Tutorial: Configure hybrid Azure Active Directory join for federated domains to learn more about setting up
Azure Active Directory Connect for a simplified join flow for Azure AD device registration.
Use this three-phased approach for configuring device registration.

1. Configure devices to register in Azure
2. Synchronize devices to on-premises Active Directory
3. Configure AD FS to use cloud devices
NOTE
Before proceeding, you should familiarize yourself with device registration concepts such as:
Azure AD registered devices
Azure AD joined devices
Hybrid Azure AD joined devices
You can learn about this and more by reading Introduction to Device Management in Azure Active Directory.
IMPORTANT
To use hybrid identity with Azure Active Directory and device WriteBack features, you must use the built-in GUI with the
latest updates for ADConnect.
Configure Azure for Device Registration

Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device
registration capabilities in Azure AD.
To do this, follow the Configure device settings steps under Setting up Azure AD Join in your organization
Configure Active Directory to support Azure device synchronization

Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises
Active Directory to support synchronizing hybrid Azure AD joined devices. Begin with upgrading the Active
Directory Schema
Upgrading Active Directory to the Windows Server 2016 or later Schema
To use Windows Hello for Business with Hybrid Azure AD joined devices, you must first upgrade your Active
Directory schema to Windows Server 2016 or later.
IMPORTANT
If you already have a Windows Server 2016 or later domain controller in your forest, you can skip Upgrading Active
Director y to the Windows Ser ver 2016 or later Schema (this section).
Identify the schema role domain controller

To locate the schema master role holder, open and command prompt and type:
Netdom query fsmo | findstr -i schema
The command should return the name of the domain controller where you need to run adprep.exe. Update the
schema locally on the domain controller hosting the Schema master role.
Updating the Schema
Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords). During
enrollment, the public key is registered in an attribute on the user object in Active Directory. The schema update
adds this new attribute to Active Directory.
Manually updating Active Directory uses the command-line utility adprep.exe located at
<drive>:\suppor t\adprep on the Windows Server 2016 or later DVD or ISO. Before running adprep.exe, you
must identify the domain controller hosting the schema master role.
Sign-in to the domain controller hosting the schema master operational role using enterprise administrator
equivalent credentials.
1. Open an elevated command prompt.
2. Type cd /d x:\support\adprep where x is the drive letter of the DVD or mounted ISO.
3. To update the schema, type adprep /forestprep .
4. Read the Adprep Warning. Type the letter C * and press Enter to update the schema.
5. Close the Command Prompt and sign-out.
NOTE
If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect
installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is
configured.
Setup Active Directory Federation Services

If you are new to AD FS and federation services, you should review Understanding Key AD FS Concepts to prior
to designing and deploying your federation service. Review the AD FS Design guide to plan your federation
service.
Once you have your AD FS design ready, review Deploying a Federation Server farm to configure AD FS in your
environment.
IMPORTANT
During your AD FS deployment, skip the Configure a federation ser ver with Device Registration Ser vice and the
Configure Corporate DNS for the Federation Ser vice and DRS procedures.
The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of
KB4088889 (14393.2155). If your AD FS farm is not running the AD FS role with updates from Windows Server
2016, then read Upgrading to AD FS in Windows Server 2016
ADFS Web Proxy
Federation server proxies are computers that run AD FS software that have been configured manually to act in
the proxy role. You can use federation server proxies in your organization to provide intermediary services
between an Internet client and a federation server that is behind a firewall on your corporate network. Use the
Setting of a Federation Proxy checklist to configure AD FS proxy servers in your environment.
Deploy Azure AD Connect
Next, you need to synchronize the on-premises Active Directory with Azure Active Directory. To do this, first
review the Integrating on-prem directories with Azure Active Directory and hardware and prerequisites needed
and then download the software.
When you are ready to install, follow the Configuring federation with AD FS section of Custom installation
of Azure AD Connect. Select the Federation with AD FS option on the User sign-in page. At the AD FS Farm
page, select the use an existing option and click Next .
Create AD objects for AD FS Device Authentication
If your AD FS farm is not already configured for Device Authentication (you can see this in the AD FS
Management console under Service -> Device Registration), use the following steps to create the correct AD DS
objects and configuration.
NOTE
The below commands require Active Directory administration tools, so if your federation server is not also a domain
controller, first install the tools using step 1 below. Otherwise you can skip step 1.
1. Run the Add Roles & Features wizard and select feature Remote Ser ver Administration Tools -> Role
Administration Tools -> AD DS and AD LDS Tools -> Choose both the Active Director y module for
Windows PowerShell and the AD DS Tools .
2. On your AD FS primary server, ensure you are logged in as AD DS user with enterprise administrator
privileges and open an elevated Windows PowerShell prompt. Then, run the following commands:
Import-module activedirectory
PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>"
3. On the pop-up window click Yes .
NOTE
If your AD FS service is configured to use a GMSA account, enter the account name in the format
"domain\accountname$"
The above PSH creates the following objects:

RegisteredDevices container under the AD domain partition
Device Registration Service container and object under Configuration --> Services --> Device Registration
Configuration
Device Registration Service DKM container and object under Configuration --> Services --> Device
Registration Configuration
4. Once this is done, you will see a successful completion message.
Create Service Connection Point (SCP) in Active Directory

If you plan to use Windows 10 domain join (with automatic registration to Azure AD) as described here, execute
the following commands to create a service connection point in AD DS
1. Open Windows PowerShell and execute the following:
PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory
Connect\AdPrep\AdSyncPrep.psm1"
NOTE
If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server. This file is located in Program
Files\Microsoft Azure Active Directory Connect\AdPrep
2. Provide your Azure AD global administrator credentials

PS C:>$aadAdminCred = Get-Credential
3. Run the following PowerShell command

PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -
AzureADCredentials $aadAdminCred
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when
adding your on-premises AD DS directory.
The above commands enable Windows 10 clients to find the correct Azure AD domain to join by creating the
serviceConnectionpoint object in AD DS.
Prepare AD for Device Write Back
To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the
following.
1. Open Windows PowerShell and execute the following:
PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD
connector account name]
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when
adding your on-premises AD DS directory in domain\accountname format
The above command creates the following objects for device write back to AD DS, if they do not exist already,
and allows access to the specified AD connector account name
RegisteredDevices container in the AD domain partition
Device Registration Service container and object under Configuration --> Services --> Device Registration
Configuration
Enable Device Write Back in Azure AD Connect
If you have not done so before, enable device write back in Azure AD Connect by running the wizard a second
time and selecting "Customize Synchronization Options" , then checking the box for device write back and
selecting the forest in which you have run the above cmdlets
Configure AD FS to use Azure registered devices

Configure issuance of claims
In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a 3rd
party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to
register against the Azure Active Directory Device Registration Service (Azure DRS).
Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint
(either 1.3 or 2005 versions) hosted by the on-premises federation service.
When you're using AD FS, you need to enable the following WS-Trust endpoints:
/adfs/services/trust/2005/windowstransport /adfs/services/trust/13/windowstransport
/adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed
/adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed
WARNING
Both adfs/ser vices/trust/2005/windowstranspor t and adfs/ser vices/trust/13/windowstranspor t should be
enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web
Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see Disable WS-Trust Windows
endpoints on the proxy. You can see what endpoints are enabled through the AD FS management console under Ser vice
> Endpoints .
NOTE
If you don’t have AD FS as your on-premises federation service, follow the instructions from your vendor to make sure
they support WS-Trust 1.3 or 2005 endpoints and that these are published through the Metadata Exchange file (MEX).
The following claims must exist in the token received by Azure DRS for device registration to complete. Azure
DRS will create a device object in Azure AD with some of this information which is then used by Azure AD
Connect to associate the newly created device object with the computer account on-premises.
http://schemas.microsoft.com/ws/2012/01/accounttype
http://schemas.microsoft.com/identity/claims/onpremobjectguid
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
If you have more than one verified domain name, you need to provide the following claim for computers:
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid
If you are already issuing an ImmutableID claim (e.g., alternate login ID) you need to provide one corresponding
claim for computers:
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
In the following sections, you find information about:

The values each claim should have
How a definition would look like in AD FS
The definition helps you to verify whether the values are present or if you need to create them.
NOTE
If you don't use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate
configuration to issue these claims.
Issue account type claim

http://schemas.microsoft.com/ws/2012/01/accounttype - This claim must contain a value of DJ , which identifies
the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue account type for domain-joined computers"

c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "DJ"
);
Issue objectGUID of the computer account on-premises

http://schemas.microsoft.com/identity/claims/onpremobjectguid - This claim must contain the objectGUID
value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like
this:
@RuleName = "Issue object GUID for domain-joined computers"
c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
query = ";objectguid;{0}",
param = c2.Value
);
Issue objectSID of the computer account on-premises

http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid - This claim must contain the objectSid
value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like
this:
@RuleName = "Issue objectSID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
]
=> issue(claim = c2);
Issue issuerID for computer when multiple verified domain names in Azure AD
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid - This claim must contain the Uniform
Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation
service (AD FS or 3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the
ones below in that specific order after the ones above. Please note that one rule to explicitly issue the rule for
users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.
@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "http://<verified-domain-name>/adfs/services/trust/"
);
In the claim above,

$<domain> is the AD FS service URL
<verified-domain-name> is a placeholder you need to replace with one of your verified domain names in
Azure AD
For more details about verified domain names, see Add a custom domain name to Azure Active Directory.
To get a list of your verified company domains, you can use the Get-MsolDomain cmdlet.
Issue ImmutableID for computer when one for users exist (e.g. alternate login ID is set)
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID - This claim must contain a valid value for
computers. In AD FS, you can create an issuance transform rule as follows:
@RuleName = "Issue ImmutableID for computers"
c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
param = c2.Value
);
Helper script to create the AD FS issuance transform rules

The following script helps you with the creation of the issuance transform rules described above.
$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains
$rule1 = '@RuleName = "Issue account type for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "DJ"
);'
$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
param = c2.Value
);'
$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
]
=> issue(claim = c2);'
=> issue(claim = c2);'
$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
Value == "DJ"
]
)
=> add(
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Value == "User"
]
=> issue(
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}
$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
param = c2.Value
);'
}
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier

urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules

$crSet.ClaimRulesString
Remarks
This script appends the rules to the existing rules. Do not run the script twice because the set of rules
would be added twice. Make sure that no corresponding rules exist for these claims (under the
corresponding conditions) before running the script again.
If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-
MsolDomains cmdlet), set the value of $multipleVerifiedDomainNames in the script to $true . Also
make sure that you remove any existing issuerid claim that might have been created by Azure AD
Connect or via other means. Here is an example for this rule:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =
regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));
If you have already issued an ImmutableID claim for user accounts, set the value of
$immutableIDAlreadyIssuedforUsers in the script to $true .
Configure Device Authentication in AD FS
Using an elevated PowerShell command window, configure AD FS policy by executing the following command
PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod
SignedToken
Check your configuration

For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for
device write-back and authentication to work
object of type ms-DS-DeviceContainer at CN=RegisteredDevices,DC=<domain>
read access to the AD FS service account
read/write access to the Azure AD Connect sync AD connector account
Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<domain>
Container Device Registration Service DKM under the above container
object of type serviceConnectionpoint at CN=<guid>, CN=Device Registration
Configuration,CN=Services,CN=Configuration,DC=<domain>
read/write access to the specified AD connector account name on the new object
object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device
Registration Configuration,CN=Services,CN=Configuration,DC=<domain>
object of type msDS-DeviceRegistrationService in the above container

deployment guide
1. Overview
2. Prerequisites
4. Configure Azure Device Registration (You are here)
Configure Windows Hello for Business
Applies to
Hybrid deployment
Certificate trust
Your environment is federated and you are ready to configure your hybrid environment for Windows Hello for
business using the certificate trust model.
IMPORTANT
If your environment is not federated, review the New Installation baseline section of this deployment document to learn
how to federate your environment for your Windows Hello for Business deployment.
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
Active Directory
Active Directory Federation Services
Group Policy
For the most efficient deployment, configure these technologies in order beginning with the Active Directory
configuration
C O N F I G U R E A C T I V E D I R E C TO R Y
>

deployment guide
1. Overview
2. Prerequisites
5. Configure Windows Hello for Business settings (You are here)
Hybrid Windows Hello for Business Provisioning
Applies to
Hybrid deployment
Certificate trust
Provisioning
The 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
The first thing to validate is the computer has processed device registration. You can view this from the User
device registration logs where the check Device is AAD joined (AADJ or DJ++): Yes appears. Additionally,
you can validate this using the dsregcmd /status command from a console prompt where the value for
AzureADJoined reads Yes .
Windows Hello for Business provisioning begins with a full screen page with the title Setup a PIN and button
with the same name. The user clicks Setup a PIN .
The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning
informs the user that it is actively attempting to contact the user through their configured form of MFA. The
provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA
results in an error and asks the user to retry.
After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe
any PIN complexity requirements that you deployed to the environment.
The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
A successful single factor authentication (username and password at sign-in)
A device that has successfully completed device registration
A fresh, successful multi-factor authentication
A validated PIN that meets the PIN complexity requirements
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for
the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired,
Windows communicates with Azure Active Directory to register the public key. AAD Connect synchronizes the
user's key to the on-premises Active Directory.
IMPORTANT
The following is the enrollment behavior prior to Windows Server 2016 update KB4088889 (14393.2155).
The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active
Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. This synchronization
latency delays the user's ability to authenticate and use on-premises resources until the user's public key
has synchronized to Active Director y. Once synchronized, the user can authenticate and use on-premises resources.
Read Azure AD Connect sync: Scheduler to view and adjust the synchronization cycle for your organization.
NOTE
Windows Server 2016 update KB4088889 (14393.2155) provides synchronous certificate enrollment during hybrid
certificate trust provisioning. With this update, users no longer need to wait for Azure AD 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.
After a successful key registration, Windows creates a certificate request using the same key pair to request a
certificate. Windows send the certificate request to the AD FS server for certificate enrollment.
The AD FS registration authority verifies the key used in the certificate request matches the key that was
previously registered. On a successful match, the AD FS registration authority signs the certificate request using
its enrollment agent certificate and sends it to the certificate authority.
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 Windows Action
Center.

deployment guide
1. Overview
2. Prerequisites
5. Configure Windows Hello for Business policy settings
6. Sign-in and Provision (You are here)
Azure AD Join Single Sign-on Deployment
Applies to
Windows 10
Azure Active Directory joined
Hybrid deployment
Windows Hello for Business combined with Azure Active Directory joined devices makes it easy for users to
securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-
premises as enterprises transition resources to the cloud and Azure AD joined devices may need to access these
resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to
your on-premises resources for Azure Active Directory joined devices using Windows Hello for Business, using a
key or a certificate.
Key vs. Certificate

Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources. Both types
of authentication provide the same security; one is not more secure than the other.
When using a key, the on-premises environment needs an adequate distribution of Windows Server 2016
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 Domain
Controllers for Windows Hello for Business deployments to learn more.
When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain
controllers, which removes the Windows Server 2016 domain controller requirement. However, single-sign on
using a certificate requires additional infrastructure to issue a certificate when the user enrolls for Windows
Hello for Business. Azure AD joined devices enroll certificates using Microsoft Intune or a compatible Mobile
Device Management (MDM). Microsoft Intune and Windows Hello for Business use the Network Device
Enrollment Services (NDES) role and support Microsoft Intune connector.
To deploy single sign-on for Azure AD joined devices using keys, read and follow Configure Azure AD joined
devices for On-premises Single-Sign On using Windows Hello for Business. To deploy single sign-on for Azure
AD joined devices using certificates, read and follow Configure Azure AD joined devices for On-premises Single-
Sign On using Windows Hello for Business and then Using Certificates for AADJ On-premises Single-sign On.
Related topics
Configure Azure AD joined devices for On-premises
Single-Sign On using Windows Hello for Business
Applies to
Windows 10
Hybrid Deployment
Key trust model
Prerequisites
Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to
verify the existing deployment can support Azure AD joined devices. Unlike hybrid Azure AD joined devices,
Azure AD joined devices do not have a relationship with your Active Directory domain. This factor changes the
way in which users authenticate to Active Directory. Validate the following configurations to ensure they support
Azure AD joined devices.
Azure Active Directory Connect synchronization
Device Registration
Certificate Revocation List (CRL) Distribution Point (CDP)
2016 Domain Controllers
Domain Controller certificate
Network infrastructure in place to reach your on-premises domain controller. If the machines are external,
this can be achieved using any VPN solution.
Azure Active Directory Connect synchronization
Azure AD join, as well as hybrid Azure AD join devices register the user's Windows Hello for Business credential
with Azure. To enable on-premises authentication, the credential must be synchronized to the on-premises
Active Directory, regardless whether you are using a key or a certificate. Ensure you have Azure AD Connect
installed and functioning properly. To learn more about Azure AD Connect, read Integrate your on-premises
directories with Azure Active Directory.
If you upgraded your Active Directory schema to the Windows Server 2016 schema after installing Azure AD
Connect, run Azure AD Connect and run Refresh director y schema from the list of tasks.
Azure Active Directory Device Registration
A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device
registration. A user cannot provision Windows Hello for Business unless the device from which they are trying
to provision has registered with Azure Active Directory. For more information about device registration, read
Introduction to device management in Azure Active Directory.
You can use the dsregcmd.exe command to determine if your device is registered to Azure Active Directory.
CRL Distribution Point (CDP)

Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it
writes information about the certificate into a revocation list. During certificate validation, Windows 10 consults
the CRL distribution point within the certificate to get a list of revoked certificates. Validation compares the
current certificate with information in the certificate revocation list to determine if the certificate remains valid.
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can
determine this because the value in the URL begins with ldap . Using Active Directory for domain joined devices
provides a highly available CRL distribution point. However, Azure Active Directory joined devices and users on
Azure Active Directory joined devices cannot read data from Active Directory, and certificate validation does not
provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular
problem as the user is attempting to authenticate, but must read Active Directory to complete the
authentication, but the user cannot read Active Directory because they have not authenticated.
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory
joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point
on a web server that uses HTTP (not HTTPS).
If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing
certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
NOTE
If your CA has published both the Base and the Delta CRL, please make sure you have included publishing the Delta CRL
in the HTTP path. Include web server to fetch the Delta CRL by allowing double escaping in the (IIS) web server.
Windows Server 2016 Domain Controllers

If you are interested in configuring your environment to use the Windows Hello for Business key rather than a
certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers.
Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for
Business key. What do we mean by adequate? We are glad you asked. Read Planning an adequate number of
Windows Server 2016 Domain Controllers for Windows Hello for Business deployments to learn more.
If you are interested in configuring your environment to use the Windows Hello for Business certificate rather
than key, then you are the right place. The same certificate configuration on the domain controllers is needed,
whether you are using Windows Server 2016 domain controllers or domain controllers running earlier versions
of Windows Server. You can simply ignore the Windows Server 2016 domain controller requirement.
Domain Controller Certificates
Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point
changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL
distribution point. The domain controller certificate is one the critical components of Azure AD joined devices
authenticating to Active Directory
Why does Windows need to validate the domain controller certificate?
Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an
Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the
Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined
device, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are
met:
The domain controller has the private key for the certificate provided.
The root CA that issued the domain controller's certificate is in the device's Trusted Root Cer tificate
Authorities .
Use the Kerberos Authentication cer tificate template instead of any other older template.
The domain controller's certificate has the KDC Authentication enhanced key usage (EKU).
The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the
domain.
The domain controller's certificate's signature hash algorithm is sha256 .
The domain controller's certificate's public key is RSA (2048 Bits) .
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not
enforce that the domain controller certificate includes the KDC Authentication EKU. If you are adding Azure
AD joined devices to an existing domain environment, make sure to verify that your domain controller
certificate has been updated to include the KDC Authentication EKU. If you need to update your domain
controller certificate to include the KDC Authentication EKU, follow the instructions in Configure Hybrid
Windows Hello for Business: Public Key Infrastructure
TIP
If you are using Windows Server 2008, Kerberos Authentication is not the default template, so make sure to use the
correct template when issuing or re-issuing the certificate.
Configuring a CRL Distribution Point for an issuing certificate

authority
Use this set of procedures to update your certificate authority that issues your domain controller certificates to
include an http-based CRL distribution point.
Steps you will perform include:
Configure Internet Information Services to host CRL distribution point
Prepare a file share to host the certificate revocation list
Configure the new CRL distribution point and Publishing location in the issuing certificate authority
Publish CRL
Reissue domain controller certificates
You need to host your new certificate revocation list of a web server so Azure AD joined devices can easily
validate certificates without authentication. You can host these files on web servers many ways. The following
steps is just one and may be useful for those unfamiliar with adding a new CRL distribution point.
IMPORTANT
Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate.
Clients should access the distribution point using http.
Installing the Web Server

1. Sign-in to your server as a local administrator and start Ser ver Manager if it did not start during your sign
in.
2. Click the Local Ser ver node in the navigation pane. Click Manage and click Add Roles and Features .
3. In the Add Role and Features Wizard , click Ser ver Selection . Verify the selected server is the local
server. Click Ser ver Roles . Select the check box next to Web Ser ver (IIS) .
4. Click Next through the remaining options in the wizard, accepting the defaults, and install the Web Server
role.
Configure the Web Server
1. From Windows Administrative Tools , Open Internet Information Ser vices (IIS) Manager .
2. Expand the navigation pane to show Default Web Site . Select and then right-click Default Web site
and click Add Vir tual Director y....
3. In the Add Vir tual Director y dialog box, type cdp in alias . For physical path, type or browse for the
physical file location where you will host the certificate revocation list. For this example, the path c:\cdp
is used. Click OK .
NOTE
Make note of this path as you will use it later to configure share and file permissions.
4. Select CDP under Default Web Site in the navigation pane. Double-click Director y Browsing in the
content pane. Click Enable in the details pane.
5. Select CDP under Default Web Site in the navigation pane. Double-click Configuration Editor .
6. In the Section list, navigate to system.webSer ver/security/requestFiltering .
In the list of named value-pairs in the content pane, configure allowDoubleEscaping to True . Click
Apply in the actions pane.
7. Close Internet Information Ser vices (IIS) Manager .
Create a DNS resource record for the CRL distribution point URL
1. On your DNS server or from an administrative workstation, open DNS Manager from Administrative
Tools .
2. Expand For ward Lookup Zones to show the DNS zone for your domain. Right-click your domain name in
the navigation pane and click New Host (A or AAAA)....
3. In the New Host dialog box, type crl in Name . Type the IP address of the web server you configured in IP
Address . Click Add Host . Click OK to close the DNS dialog box. Click Done .
4. Close the DNS Manager .

These procedures configure NTFS and share permissions on the web server to allow the certificate authority to
automatically publish the certificate revocation list.
Configure the CDP file share
1. On the web server, open Windows Explorer and navigate to the cdp folder you created in step 3 of
Configure the Web Server.
2. Right-click the cdp folder and click Proper ties . Click the Sharing tab. Click Advanced Sharing .
3. Select Share this folder . Type cdp$ in Share name . Click Permissions .
4. In the Permissions for cdp$ dialog box, click Add .

5. In the Select Users, Computers, Ser vice Accounts, or Groups dialog box, click Object Types . In the
Object Types dialog box, select Computers , and then click OK .
6. In the Select Users, Computers, Ser vice Accounts, or Groups dialog box, in Enter the object names
to select , type the name of the server running the certificate authority issuing the certificate revocation list,
and then click Check Names . Click OK .
7. In the Permissions for cdp$ dialog box, select the certificate authority from the Group or user names
list . In the Permissions for section, select Allow for Full control . Click OK .
8. In the Advanced Sharing dialog box, click OK .
TIP
Make sure that users can access \\Ser ver FQDN\sharename .
Disable Caching
2. Right-click the cdp folder and click Proper ties . Click the Sharing tab. Click Advanced Sharing .
3. Click Caching . Select No files or programs from the shared folder are available offline .
4. Click OK .
Configure NTFS permission for the CDP folder
2. Right-click the cdp folder and click Proper ties . Click the Security tab.
3. On the Security tab, click Edit.
4. In the Permissions for cdp dialog box, click Add .
5. In the Select Users, Computers, Ser vice Accounts, or Groups dialog box, click Object Types . In the
Object Types dialog box, select Computers . Click OK .
6. In the Select Users, Computers, Ser vice Accounts, or Groups dialog box, in Enter the object names
to select , type the name of the certificate authority, and then click Check Names . Click OK .
7. In the Permissions for cdp dialog box, select the name of the certificate authority from the Group or user
names list. In the Permissions for section, select Allow for Full control . Click OK .
8. Click Close in the cdp Proper ties dialog box.
Configure the new CRL distribution point and Publishing location in the issuing certificate authority
The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to
publish the CRL at the new location and to include the new CRL distribution point
Configure the CRL distribution Point
1. On the issuing certificate authority, sign-in as a local administrator. Start the Cer tificate Authority console
from Administrative Tools .
2. In the navigation pane, right-click the name of the certificate authority and click Proper ties
3. Click Extensions . On the Extensions tab, select CRL Distribution Point (CDP) from the Select
extension list.
4. On the Extensions tab, click Add . Type http://crl.[domainname]/cdp/ in location . For example,
http://crl.corp.contoso.com/cdp/ or http://crl.contoso.com/cdp/ (do not forget the trailing forward slash).
5. Select <CaName> from the Variable list and click Inser t . Select <CRLNameSuffix> from the Variable
list and click Inser t . Select <DeltaCRL Allowed> from the Variable list and click Inser t .
6. Type .crl at the end of the text in Location . Click OK .
7. Select the CDP you just created.

8. Select Include in CRLs. Clients use this to find Delta CRL locations .
9. Select Include in the CDP extension of issued cer tificates .
10. Click Apply save your selections. Click No when ask to restart the service.
NOTE
Optionally, you can remove unused CRL distribution points and publishing locations.
Configure the CRL publishing location

2. In the navigation pane, right-click the name of the certificate authority and click Proper ties
3. Click Extensions . On the Extensions tab, select CRL Distribution Point (CDP) from the Select
extension list.
4. On the Extensions tab, click Add . Type the computer and share name you create for your CRL distribution
point in Configure the CDP file share. For example, \\app\cdp$\ (do not forget the trailing backwards slash).
5. Select <CaName> from the Variable list and click Inser t . Select <CRLNameSuffix> from the Variable
list and click Inser t . Select <DeltaCRL Allowed> from the Variable list and click Inser t .
6. Type .crl at the end of the text in Location . Click OK .
7. Select the CDP you just created.

8. Select Publish CRLs to this location .
9. Select Publish Delta CRLs to this location .
10. Click Apply save your selections. Click Yes when ask to restart the service. Click OK to close the properties
dialog box.
Publish a new CRL
2. In the navigation pane, right-click Revoked Cer tificates , hover over All Tasks , and click Publish
3. In the Publish CRL dialog box, select New CRL and click OK .
Validate CDP Publishing
Validate your new CRL distribution point is working.
1. Open a web browser. Navigate to http://crl.[yourdomain].com/cdp . You should see two files created from
publishing your new CRL.
With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates
to domain controllers as the old certificate does not have the updated CRL distribution point.
1. Sign-in a domain controller using administrative credentials.
2. Open the Run dialog box. Type cer tlm.msc to open the Cer tificate Manager for the local computer.
3. In the navigation pane, expand Personal . Click Cer tificates . In the details pane, select the existing domain
controller certificate includes KDC Authentication in the list of Intended Purposes .
4. Right-click the selected certificate. Hover over All Tasks and then select Renew Cer tificate with New
Key.... In the Cer tificate Enrollment wizard, click Next .
5. In the Request Cer tificates page of the wizard, verify the selected certificate has the correct certificate
template and ensure the status is available. Click Enroll .
6. After the enrollment completes, click Finish to close the wizard.
7. Repeat this procedure on all your domain controllers.
NOTE
You can configure domain controllers to automatically enroll and renew their certificates. Automatic certificate enrollment
helps prevent authentication outages due to expired certificates. Refer to the Windows Hello Deployment Guides to learn
how to deploy automatic certificate enrollment for domain controllers.
IMPORTANT
If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the
certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two
people know when these certificates expire.
Validate CDP in the new certificate

3. In the navigation pane, expand Personal . Click Cer tificates . In the details pane, double-click the existing
domain controller certificate includes KDC Authentication in the list of Intended Purposes .
4. Click the Details tab. Scroll down the list until CRL Distribution Points is visible in the Field column of the
list. Select CRL Distribution Point .
5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is
present in the certificate. Click OK .
Configure and Assign a Trusted Certificate Device Configuration
Profile
Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your
enterprise root certificate so you can deploy it to Azure AD joined devices. Deploying the enterprise root
certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the
certificate, Azure AD joined devices do not trust domain controller certificates and authentication fails.
Export Enterprise Root certificate
Create and Assign a Trust Certificate Device Configuration Profile
3. In the navigation pane, expand Personal . Click Cer tificates . In the details pane, double-click the existing
domain controller certificate includes KDC Authentication in the list of Intended Purposes .
4. Click the Cer tification Path tab. In the Cer tification path view, select the top most node and click View
Cer tificate .
5. In the new Cer tificate dialog box, click the Details tab. Click Copy to File .
6. In the Cer tificate Expor t Wizard , click Next .

7. On the Expor t File Format page of the wizard, click Next .
8. On the File to Expor t page in the wizard, type the name and location of the root certificate and click Next .
Click Finish and then click OK to close the success dialog box.
9. Click OK two times to return to the Cer tificate Manager for the local computer. Close the Cer tificate
Manager .
A Trusted Cer tificate device configuration profile is how you deploy trusted certificates to Azure AD joined
devices.
1. Sign-in to the Microsoft Azure Portal and select Microsoft Intune .
2. Click Device configuration . In the Device Configuration blade, click Create profile .
3. In the Create profile blade, type Enterprise Root Cer tificate in Name . Provide a description. Select
Windows 10 and later from the Platform list. Select Trusted cer tificate from the Profile type list. Click
Configure .
4. In the Trusted Cer tificate blade, use the folder icon to browse for the location of the enterprise root
certificate file you created in step 8 of Export Enterprise Root certificate. Click OK . Click Create .
5. In the Enterprise Root Cer tificate blade, click Assignments . In the Include tab, select All Devices from
the Assign to list. Click Save .
6. Sign out of the Microsoft Azure Portal.

NOTE
After the creation, the suppor ted platform parameter of the profile will contain the value "Windows 8.1 and later", as
the certificate configuration for Windows 8.1 and Windows 10 is the same.
Configure Windows Hello for Business Device Enrollment

Sign-in a workstation with access equivalent to a domain user.
1. Sign in to the Microsoft Endpoint Manager admin center.
2. Select Devices .
3. Choose Enroll devices .
4. Select Windows enrollment .
5. Under Windows enrollment , select Windows Hello for Business .
6. Select Enabled from the Configure Windows Hello for Business list.
7. Select Required next to Use a Trusted Platform Module (TPM) . By default, Windows Hello for
Business prefers TPM 2.0 or falls backs to software. Choosing Required forces Windows Hello for
Business to only use TPM 2.0 or TPM 1.2 and does not allow fall back to software-based keys.
8. Enter the desired Minimum PIN length and Maximum PIN length .
IMPORTANT
The default minimum PIN length for Windows Hello for Business on Windows 10 is six. Microsoft Intune defaults
the minimum PIN length to four, which reduces the security of the user's PIN. If you do not have a desired PIN
length, set the minimum PIN length to six.
9. Select the appropriate configuration for the following settings:

Lowercase letters in PIN
Uppercase letters in PIN
Special characters in PIN
PIN expiration (days)
Remember PIN histor y
NOTE
The Windows Hello for Business PIN is not a symmetric key (a password). A copy of the current PIN is not stored
locally or on a server like in the case of passwords. Making the PIN as complex and changed frequently as a
password increases the likelihood of forgotten PINs. Additionally, enabling PIN history is the only scenario that
requires Windows 10 to store older PIN combinations (protected to the current PIN). Windows Hello for Business
combined with a TPM provides anti-hammering functionality that prevents brute force attacks of the user's PIN. If
you are concerned with user-to-user shoulder surfacing, rather that forcing complex PIN that change frequently,
consider using the Multifactor Unlock feature.
10. Select Yes next to Allow biometric authentication if you want to allow users to use biometrics
(fingerprint and/or facial recognition) to unlock the device. To further secure the use of biometrics, select
Yes to Use enhanced anti-spoofing, when available .
11. Select No to Allow phone sign-in . This feature has been deprecated.
12. Choose Save .
13. Sign out of the Microsoft Endpoint Manager admin center.
IMPORTANT
For more details about the actual experience after everything has been configured, please see Windows Hello for Business
and Authentication.
Section Review
Configure the new CRL distribution point in the issuing certificate authority
Publish CRL
Configure Windows Hello for Business Device Enrollment
If you plan on using certificates for on-premises single-sign on, perform the additional steps in Using
Certificates for On-premises Single-sign On.
Using Certificates for AADJ On-premises Single-
sign On
Applies to:
Windows 10
Hybrid Deployment
Certificate trust
If you plan to use certificates for on-premises single-sign on, then follow these additional steps to configure
the environment to enroll Windows Hello for Business certificates for Azure AD joined devices.
IMPORTANT
Ensure you have performed the configurations in Azure AD joined devices for On-premises Single-Sign On before you
continue.

Prepare Azure AD Connect
Prepare the Network Device Enrollment Services Service Account
Prepare Active Directory Certificate Services
Install the Network Device Enrollment Services Role
Configure Network Device Enrollment Services to work with Microsoft Intune
Download, Install and Configure the Intune Certificate Connector
Create and Assign a Simple Certificate Enrollment Protocol (SCEP) Certificate Profile
Requirements
You need to install and configure additional infrastructure to provide Azure AD joined devices with on-premises
single-sign on.
An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
High Availaibilty
The Network Device Enrollment Services (NDES) server role acts as a certificate registration authority.
Certificate registration servers enroll certificates on behalf of the user. Users request certificates from the NDES
service rather than directly from the issuing certificate authority.
The architecture of the NDES server prevents it from being clustered or load balanced for high availability. To
provide high availability, you need to install more than one identically configured NDES servers and use
Microsoft Intune to load balance then (in round-robin fashion).
The Network Device Enrollment Service (NDES) server role can issue up to three unique certificate templates.
The server role accomplishes this by mapping the purpose of the certificate request to a configured certificate
template. The certificate request purpose has three options:
Signature
Encryption
Signature and Encryption
If you need to deploy more than three types of certificates to the Azure AD joined device, you need additional
NDES servers. Alternatively, consider consolidating certificate templates to reduce the number of certificate
templates.
Network Requirements
All communication occurs securely over port 443.

Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint
about the on-premises domain. The hint can be the user's Active Directory distinguished name as the subject of
the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory
domain name.
Most environments change the user principal name suffix to match the organization's external domain name (or
vanity domain), which prevents the user principal name as a hint to locate a domain controller. Therefore, the
certificate needs the user's on-premises distinguished name in the subject to properly locate a domain
controller.
To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the
Active Directory distinguishedName attribute to the Azure Active Directory
onPremisesDistinguishedName attribute. Azure AD Connect version 1.1.819 includes the proper
synchronization rules needed for these attributes.
Verify AAD Connect version
Sign-in to computer running Azure AD Connect with access equivalent to local administrator.
1. Open Synchronization Ser vices from the Azure AD Connect folder.
2. In the Synchronization Ser vice Manager , click Help and then click About .
3. If the version number is not 1.1.819 or later, then upgrade Azure AD Connect to the latest version.
Verify the onPremisesDistinguishedName attribute is synchronized
The easiest way to verify the onPremisesDistingushedNamne attribute is synchronized is to use Azure AD Graph
Explorer.
1. Open a web browser and navigate to https://graphexplorer.azurewebsites.net/
2. Click Login and provide Azure credentials
3. In the Azure AD Graph Explorer URL, type https://graph.windows.net/myorganization/users/[userid], where
[userid] is the user principal name of user in Azure Active Directory. Click Go
4. In the returned results, review the JSON data for the onPremisesDistinguishedName attribute. Ensure the
attribute has a value and the value is accurate for the given user.
Prepare the Network Device Enrollment Services (NDES) Service
Account
Create the NDES Servers global security group
The deployment uses the NDES Ser vers security group to assign the NDES service the proper user right
assignments.
Sign-in to a domain controller or management workstation with access equivalent to domain administrator.
1. Open Active Director y Users and Computers .
2. Expand the domain node from the navigation pane.
3. Right-click the Users container. Hover over New and click Group .
4. Type NDES Ser vers in the Group Name text box.
5. Click OK .
Add the NDES server to the NDES Servers global security group
3. Click Computers from the navigation pane. Right-click the name of the NDES server that will host the NDES
server role. Click Add to a group....
4. Type NDES Ser vers in Enter the object names to select . Click OK . Click OK on the Active Director y
Domain Ser vices 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.
Create the NDES Service Account

The Network Device Enrollment Services (NDES) role runs under a service account. Typically, it is preferential to
run services using a Group Managed Service Account (GMSA). While the NDES role can be configured to run
using a GMSA, the Intune Certificate Connector was not designed nor tested using a GMSA and is considered an
unsupported configuration. The deployment uses a normal services account.
1. In the navigation pane, expand the node that has your domain name. Select Users .
2. Right-click the Users container. Hover over New and then select User . Type NDESSvc in Full Name and
User logon name . Click Next .
3. Type a secure password in Password . Confirm the secure password in Confirm Password . Clear User
must change password at next logon . Click Next .
4. Click 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.
Create the NDES Service User Rights Group Policy object

The Group Policy object ensures the NDES Service account has the proper user right to assign all the NDES
servers in the NDES Ser vers group. As you add new NDES servers to your environment and this group, the
service account automatically receives the proper user rights through the Group Policy.
Sign-in a domain controller or management workstations with Domain Admin equivalent credentials.
1. Start the Group Policy Management Console (gpmc.msc)
2. Expand the domain and select the Group Policy Object node in the navigation pane.
3. Right-click Group Policy object and select New .
4. Type NDES Ser vice Rights in the name box and click OK .
5. In the content pane, right-click the NDES Ser vice Rights Group Policy object and click Edit .
6. In the navigation pane, expand Policies under Computer Configuration .
7. Expand Windows Settings > Security Settings > Local Policies . Select User Rights Assignments .
8. In the content pane, double-click Allow log on locally . Select Define these policy settings and click OK .
Click Add User or Group.... In the Add User or Group dialog box, click Browse . In the Select Users,
Computers, Ser vice 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 . Click OK twice.
9. In the content pane, double-click Log on as a batch job . Select Define these policy settings and click
OK . Click Add User or Group.... In the Add User or Group dialog box, click Browse . In the Select Users,
Computers, Ser vice 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 . Click OK twice.
10. In the content pane, double-click Log on as a ser vice . Select Define these policy settings and click OK .
Click Add User or Group.... In the Add User or Group dialog box, click Browse . In the Select Users,
Computers, Ser vice 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 . Click OK three times.
11. Close the Group Policy Management Editor .
Configure security for the NDES Service User Rights Group Policy object
The best way to deploy the NDES Ser vice User Rights Group Policy object is to use security group filtering.
This enables you to easily manage the computers that receive the Group Policy settings by adding them to a
group.
3. Double-click the NDES Ser vice User Rights Group Policy object.
4. In the Security Filtering section of the content pane, click Add . Type NDES Ser vers or the name of the
security group you previously created and click OK .
5. Click the Delegation tab. Select Authenticated Users and click Advanced .
6. 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. Click OK .
Deploy the NDES Service User Rights Group Policy object
The application of the NDES Ser vice User Rights Group Policy object uses security group filtering. This
enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all
computers. However, the security group filtering ensures only computers included in the NDES Ser vers global
security group receive and apply the Group Policy object, which results in providing the NDESSvc service
account with the proper user rights.
2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain
name and click Link an existing GPO
3. In the Select GPO dialog box, select NDES Ser vice User Rights or the name of the Group Policy object
you previously created and click OK .
IMPORTANT
Linking the NDES Ser vice 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 Ser vers global security group receive the policy settings. All others computers ignore the Group
Policy object.
Prepare Active Directory Certificate Authority

You must prepare the public key infrastructure and the issuing certificate authority to support issuing
certificates using Microsoft Intune and the Network Devices Enrollment Services (NDES) server role. In this task,
you will
Configure the certificate authority to let Intune provide validity periods
Create an NDES-Intune Authentication Certificate template
Create an Azure AD joined Windows Hello for Business authentication certificate template
Publish certificate templates
Configure the certificate authority to let Intune provide validity periods
When deploying certificates using Microsoft Intune, you have the option of providing the validity period in the
SCEP certificate profile rather than relying on the validity period in the certificate template. If you need to issue
the same certificate with different validity periods, it may be advantageous to use the SCEP profile, given the
limited number of certificates a single NDES server can issue.
NOTE
Skip this step if you do not want to enable Microsoft Intune to specify the validity period of the certificate. Without this
configuration, the certificate request uses the validity period configured in the certificate template.
Sign-in to the issuing certificate authority with access equivalent to local administrator.
1. Open an elevated command prompt and type the following command:
certutil -setreg Policy\EditFlags +EDITF_ATTRIBUTEENDDATE
2. Restart the Active Director y Cer tificate Ser vices service.

Create an NDES -Intune authentication certificate template
NDES uses a server authentication certificate to authenticate the server endpoint, which encrypts the
communication between it and the connecting client. The Intune Certificate Connector uses a client
authentication certificate template to authenticate to the certificate registration point.
Sign-in to the issuing certificate authority or management workstations with Domain Admin equivalent
credentials.
1. Open the Cer tificate Authority management console.
2. Right-click Cer tificate Templates and click Manage .
3. In the Cer tificate Template Console , right-click the Computer template in the details pane and click
Duplicate Template .
4. 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.
5. On the Subject tab, select Supply in the request .

6. On the Cr yptography tab, validate the Minimum key size is 2048 .
7. On the Security tab, click Add .
8. Type NDES ser ver in the Enter the object names to select text box and click OK .
9. Select NDES ser ver 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 are not already
cleared. Click OK .
10. Click on the Apply to save changes and close the console.
Create an Azure AD joined Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows 10 requests an authentication certificate from
Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the
Windows Hello for Business authentication certificate template. You use the name of the certificate template
when configuring the NDES Server.
Sign in a certificate authority or management workstations with Domain Admin equivalent credentials.
3. Right-click the Smar tcard Logon template and choose Duplicate Template .
4. On the Compatibility tab, clear the Show resulting changes check box. Select Windows Ser ver
2012 or Windows Ser ver 2012 R2 from the Cer tification Authority list. Select Windows Ser ver
2012 or Windows Ser ver 2012 R2 from the Cer tification Recipient list.
5. On the General tab, type AADJ 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.
6. On the Cr yptography tab, select Key Storage Provider from the Provider Categor y list. Select RSA
from the Algorithm name list. Type 2048 in the Minimum key size text box. Select SHA256 from the
Request hash list.
7. On the Extensions tab, verify the Application Policies extension includes Smar t Card Logon .
8. On the Subject tab, select Supply in the request .
9. On the Request Handling tab, select Signature and encr yption from the Purpose list. Select the
Renew with same key check box. Select Enroll subject without requiring any user input .
10. On the Security tab, click Add . Type NDESSvc in the Enter the object names to select text box and
click OK .
11. Select NDESSvc from the Group or users names list. In the Permissions for NDES Ser vers 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
are not already cleared. Click OK .
12. Close the console.
Publish certificate templates
The certificate authority may only issue certificates for certificate templates that are published to that certificate
authority. If you have more than one certificate authority and you want that certificate authority to issue
certificates based on a specific certificate template, then you must publish the certificate template to all
certificate authorities that are expected to issue the certificate.
IMPORTANT
Ensure you publish the AADJ WHFB Authentication certificate templates to the certificate authority that Microsoft
Intune uses by way of the NDES servers. The NDES configuration asks you to choose a certificate authority from which it
requests certificates. You need to publish that certificate templates to that issuing certificate authority. The NDES-Intune
Authentication certificate is directly enrolled and can be published to any certificate authority.
Sign-in to the certificate authority or management workstations with an Enterprise Admin equivalent
credentials.
2. Expand the parent node from the navigation pane.
3. Click Cer tificate Templates in the navigation pane.
4. Right-click the Cer tificate Templates node. Click New , and click Cer tificate Template to issue.
5. In the Enable Cer tificates Templates window, select the NDES-Intune Authentication and AADJ
WHFB Authentication templates you created in the previous steps. Click OK to publish the selected
certificate templates to the certificate authority.
Install and Configure the NDES Role

This section includes the following topics:
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.
Enroll for an NDES-Intune Authentication Certificate
Configure the Web Server Certificate for NDES
Verify the configuration
Install the Network Device Enrollment Services Role
Install the Network Device Enrollment Service role on a computer other than the issuing certificate authority.
credentials.
1. Open Ser ver Manager on the NDES server.
2. Click Manage . Click Add Roles and Features .
3. In the Add Roles and Features Wizard , on the Before you begin page, click Next . Select Role-based or
feature-based installation on the Select installation type page. Click Next . Click Select a ser ver
from the ser ver pool . Select the local server from the Ser ver Pool list. Click Next .
4. On the Select ser ver roles page, select Active Director y Cer tificate Ser vices from the Roles list.
Click Add Features on the Add Roles and Feature Wizard dialog box. Click Next .
5. On the Features page, expand .NET Framework 3.5 Features . Select HTTP Activation . Click Add
Features on the Add Roles and Feature Wizard dialog box. Expand .NET Framework 4.5 Features .
Expand WCF Ser vices . Select HTTP Activation . Click Add Features on the Add Roles and Feature
Wizard dialog box. Click Next .
6. On the Select role ser vices page, clear the Cer tificate Authority check box. Select the Network Device
Enrollment Ser vice . Click Add Features on the Add Roles and Features Wizard dialog box. Click Next .
7. Click Next on the Web Ser ver Role (IIS) page.

8. On the Select role ser vices page for the Web Serve role, Select the following additional services if they are
not already selected and then click Next .
Web Ser ver > Security > Request Filtering
Web Ser ver > Application Development > ASP.NET 3.5 .
Web Ser ver > 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
9. Click 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
Configure the NDES service account
This task adds the NDES service account to the local IIS_USRS group. The task also configures the NDES service
account for Kerberos authentication and delegation
Add the NDES service account to the IIS_USRS group
Sign-in the NDES server with access equivalent to local administrator.
1. Start the Local Users and Groups management console ( lusrmgr.msc ).
2. Select Groups from the navigation pane. Double-click the IIS_IUSRS group.
3. In the IIS_IUSRS Proper ties dialog box, click Add . Type NDESSvc or the name of your NDES service
account. Click Check Names to verify the name and then click OK . Click OK to close the properties dialog
box.
4. Close the management console.
Register a Service Principal Name on the NDES Service account
Sign-in the NDES server with access equivalent to Domain Admins.
2. Type the following command to register the service principal name
setspn -s http/[FqdnOfNdesServer] [DomainName\\NdesServiceAccount]
where [FqdnOfNdesSer ver] is the fully qualified domain name of the NDES server and
[DomainName\NdesSer viceAccount] is the domain name and NDES service account name separated by
a backslash (\). An example of the command looks like the following:
setspn -s http/ndes.corp.contoso.com contoso\ndessvc
NOTE
If you use the same service account for multiple NDES Servers, repeat the following task for each NDES server under
which the NDES service runs.
Configure the NDES Service account for delegation

The NDES service enrolls certificates on behalf of users. Therefore, you want to limit the actions it can perform
on behalf of the user. You do this through delegation.
Sign-in a domain controller with a minimum access equivalent to Domain Admins.
1. Open Active Director y Users and Computers
2. Locate the NDES Service account (NDESSvc). Right-click and select Proper ties . Click the Delegation tab.
3. Select Trust this user for delegation to specified ser vices only .
4. Select Use any authentication protocol .
5. Click Add .
6. Click Users or Computers... Type the name of the NDES Server you use to issue Windows Hello for
Business authentication certificates to Azure AD joined devices. From the Avaiable ser vices list, select
HOST . Click OK .
7. Repeat steps 5 and 6 for each NDES server using this service account. Click Add .
8. Click 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 Azure AD joined devices. From the
Available ser vices list, select dcom . Hold the CTRL key and select HOST . Click OK .
9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request
certificates.
10. Click OK . Close Active Director y Users and Computers .
Configure the NDES Role and Certificate Templates
This task configures the NDES role and the certificate templates the NDES server issues.
Configure the NDES Role
credentials.
NOTE
If you closed Server Manger from the last set of tasks, start Server Manager and click the action flag that shows a yellow
exclamation point.
1. Click the Configure Active Director y Cer tificate Ser vices on the destination ser ver link.
2. On the Credentials page, click Next .
3. On the Role Ser vices page, select Network Device Enrollment Ser vice and then click Next
4. On the Ser vice Account for NDES page, select Specify ser vice account (recommended) . Click
Select.... Type the user name and password for the NDES service account in the Windows Security dialog
box. Click Next .
5. On the CA for NDES page, select CA name . Click Select.... Select the issuing certificate authority from
which the NDES server requests certificates. Click Next .
6. On the RA Information , click Next .

7. On the Cr yptography for NDES page, click Next .
8. Review the Confirmation page. Click Configure .
9. Click Close after the configuration completes.
Configure Certificate Templates on NDES
A single NDES server can request a maximum of three certificate templates. The NDES server determines which
certificate to issue based on the incoming certificate request that is assigned in the Microsoft Intune SCEP
certificate profile. The Microsoft Intune SCEP certificate profile has three values.
Digital Signature
Key Encipherment
Key Encipherment, Digital Signature
Each value maps to a registry value name in the NDES server. The NDES server translates an incoming SCEP
provided value into the corresponding certificate template. The table below shows the SCEP profile values of the
NDES certificate template registry value names.
SC EP P RO F IL E K EY USA GE N DES REGIST RY VA L UE N A M E
Digital Signature SignatureTemplate
Key Encipherment EncryptionTemplate
Key Encipherment GeneralPurposeTemplate

Digital Signature
Ideally, you should match the certificate request with the registry value name to keep the configuration intuitive
(encryption certificates use the encryption template, signature certificates use the signature template, etc.). A
result of this intuitive design is the potential exponential growth in the NDES server. Imagine an organization
that needs to issue nine unique signature certificates across their enterprise.
If the need arises, you can configure a signature certificate in the encryption registry value name or an
encryption certificate in the signature registry value to maximize the use of your NDES infrastructure. This
unintuitive design requires current and accurate documentation of the configuration to ensure the SCEP
certificate profile is configured to enroll the correct certificate, regardless of the actual purpose. Each
organization needs to balance ease of configuration and administration with additional NDES infrastructure and
the management overhead that comes with it.
Sign-in to the NDES Server with local administrator equivalent credentials.
2. Using the table above, decide which registry value name you will use to request Windows Hello for Business
authentication certificates for Azure AD joined devices.
3. Type the following command:
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d

[certificateTemplateName]
where registr yValueName is one of the three value names from the above table and where
cer tificateTemplateName is the name of the certificate template you created for Windows Hello for
Business Azure AD joined devices. Example:
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d

AADJWHFBAuthentication
4. Type Y when the command asks for permission to overwrite the existing value.
5. Close the command prompt.
IMPORTANT
Use the name of the certificate template; not the display name . The certificate template name does not include spaces.
You can view the certificate names by looking at the General tab of the certificate template's properties in the
Cer tificates Templates management console ( certtmpl.msc ).
Create a Web Application Proxy for the internal NDES URL.

Certificate enrollment for Azure AD joined devices occurs over the Internet. As a result, the internal NDES URLs
must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy.
Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-
premises, such as Network Device Enrollment Services.
Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This
enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES
Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends
these requests to Azure AD Application Proxies.
Azure AD Application proxies are serviced by lightweight Application Proxy Connector agents. See What is
Application Proxy for more details. These agents are installed on your on-premises, domain joined devices and
make authenticated secure outbound connection to Azure, waiting to process requests from Azure AD
Application Proxies. You can create connector groups in Azure Active Directory to assign specific connectors to
service specific applications.
Connector group automatically round-robin, load balance the Azure AD Application proxy requests to the
connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests
have multiple dedicated Azure AD Application Proxy connectors exclusively available to satisfy enrollment
requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for
Business certificates in a timely manner.
Download and Install the Application Proxy Connector Agent
1. Sign-in to the Azure Portal with access equivalent to Global Administrator .
2. Select All Ser vices . Type Azure Active Director y to filter the list of services. Under SERVICES , Click
Azure Active Director y .
3. Under MANAGE , click Application proxy .
4. Click Download connector ser vice . Click Accept terms & Download . Save the file
(AADApplicationProxyConnectorInstaller.exe) in a location accessible by others on the domain.
5. Sign-in the computer that will run the connector with access equivalent to a domain user.
IMPORTANT
Install a minimum of two Azure Active Directory Proxy connectors for each NDES Application Proxy. Strategically
locate Azure AD 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.
6. Start AADApplicationProxyConnectorInstaller.exe .
7. Read the license terms and then select I agree to the license terms and conditions . Click Install .
8. Sign-in to Microsoft Azure with access equivalent to Global Administrator .
9. When the installation completes. Read the information regarding outbound proxy servers. Click Close .
10. Repeat steps 5 - 10 for each device that will run the Azure AD Application Proxy connector for Windows
Hello for Business certificate deployments.
Create a Connector Group
4. Click New Connector Group . Under Name , type NDES WHFB Connectors .
5. Select each connector agent in the Connectors list that will service Windows Hello for Business certificate
enrollment requests.
6. Click Save .
Create the Azure Application Proxy
4. Click Configure an app .
5. Under Basic Settings next to Name , type WHFB NDES 01 . Choose a name that correlates this Azure
AD Application Proxy setting with the on-premises NDES server. Each NDES server must have its own
Azure AD Application Proxy as two NDES servers cannot share the same internal URL.
6. Next to Internal URL , type the internal, fully qualified DNS name of the NDES server associated with this
Azure AD Application Proxy. For example, https://ndes.corp.mstepdemo.net). You need to match the
primary host name (AD Computer Account name) of the NDES server, and prefix the URL with https .
7. Under Internal URL , select https:// from the first list. In the text box next to https:// , type the hostname
you want to use as your external hostname for the Azure AD Application Proxy. In the list next to the
hostname you typed, select a DNS suffix you want to use externally for the Azure AD Application Proxy. It
is recommended to use the default, -[tenantName].msapproxy.net where [tenantName] is your current
Azure Active Directory tenant name (-mstephendemo.msappproxy.net).
8. Select Passthrough from the Pre Authentication list.
9. Select NDES WHFB Connectors from the Connector Group list.
10. Under Additional Settings , select Default from Backend Application Timeout . Under the Translate
URLs In section, select Yes next to Headers and select No next to Application Body .
11. Click Add .
12. Sign-out of the Azure Portal.
IMPORTANT
Write down the internal and external URLs. You will need this information when you enroll the NDES-Intune
Authentication certificate.
Enroll the NDES -Intune Authentication certificate

This task enrolls a client and server authentication certificate used by the Intune connector and the NDES server.
Sign-in the NDES server with access equivalent to local administrators.
1. Start the Local Computer Cer tificate Manager (certlm.msc).
2. Expand the Personal node in the navigation pane.
3. Right-click Personal . Select All Tasks and Request New Cer tificate .
4. Click Next on the Before You Begin page.
5. Click Next on the Select Cer tificate Enrollment Policy page.
6. On the Request Cer tificates page, Select the NDES-Intune Authentication check box.
7. Click the More information is required to enroll for this cer tificate. Click here to configure
settings link
8. 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 click Add .
9. 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 ). Click Add . Type the external URL used in the
previous task (without the https://, for example ndes-mstephendemo.msappproxy.net ). Click Add . Click
OK when finished.
10. Click Enroll
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication
certificates for Azure AD joined devices.
Configure the Web Server Role
This task configures the Web Server role on the NDES server to use the server authentication certificate.
1. Start Internet Information Ser vices (IIS) Manager from Administrative Tools .
2. Expand the node that has the name of the NDES server. Expand Sites and select Default Web Site .
3. Click Bindings...* under Actions . Click Add .
4. Select https from Type . Confirm the value for Por t is 443 .
5. Select the certificate you previously enrolled from the SSL cer tificate list. Select OK .
6. Select http from the Site Bindings list. Click Remove .
7. Click Close on the Site Bindings dialog box.
8. Close Internet Information Ser vices (IIS) Manager .
Verify the configuration
This task confirms the TLS configuration for the NDES server.
Disable Internet Explorer Enhanced Security Configuration
1. Open Ser ver Manager . Click Local Ser ver from the navigation pane.
2. Click On next to IE Enhanced Security Configuration in the Proper ties section.
3. In the Internet Explorer Enhanced Security Configuration dialog, under Administrators , select Off .
Click OK .
4. Close Ser ver Manager .
Test the NDES web server
1. Open Internet Explorer .
2. In the navigation bar, type
https://[fqdnHostName]/certsrv/mscep/mscep.dll
where [fqdnHostName] is the fully qualified internal DNS host name of the NDES server.
A web page similar to the following should appear in your web browser. If you do not see a similar page, or you
get a 503 Ser vice unavailable message, ensure the NDES Service account has the proper user rights. You can
also review the application event log for events with the NetworkDeviceEnrollmentSerice source.
Confirm the web site uses the server authentication certificate.
Configure Network Device Enrollment Services to work with Microsoft

Intune
You have successfully configured the Network Device Enrollment Services. You must now modify the
configuration to work with the Intune Certificate Connector. In this task, you will enable the NDES server and
http.sys to handle long URLs.
Configure NDES to support long URLs
Configure NDES and HTTP to support long URLs
Configure the Default Web Site
1. Start Internet Information Ser vices (IIS) Manager from Administrative Tools .
2. Expand the node that has the name of the NDES server. Expand Sites and select Default Web Site .
3. In the content pane, double-click Request Filtering . Click Edit Feature Settings... in the action pane.
4. Select Allow unlisted file name extensions .
5. Select Allow unlisted verbs .
6. Select Allow high-bit characters .
7. Type 30000000 in Maximum allowed content length (Bytes) .
8. Type 65534 in Maximum URL length (Bytes) .
9. Type 65534 in Maximum quer y string (Bytes) .
10. Click OK . Close Internet Information Ser vices (IIS) Manager .
Configure Parameters for HTTP.SYS
2. Run the following commands:
reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d

65534
reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d
65534
3. Restart the NDES server.
Download, Install and Configure the Intune Certificate Connector

The Intune Certificate Connector application enables Microsoft Intune to enroll certificates using your on-
premises PKI for users on devices managed by Microsoft Intune.
Download Intune Certificate Connector
1. Sign-in to the Microsoft Endpoint Manager admin center.
2. Select Tenant administration > Connectors and tokens > Cer tificate connectors > Add .
3. Click Download the cer tificate connector software under the Install Cer tificate Connectors section.
4. Save the downloaded file (NDESConnectorSetup.exe) to a location accessible from the NDES server.
5. Sign-out of the Microsoft Endpoint Manager admin center.
Install the Intune Certificate Connector
Sign-in the NDES server with access equivalent to domain administrator.
1. Copy the Intune Certificate Connector Setup (NDESConnectorSetup.exe) downloaded in the previous task
locally to the NDES server.
2. Run NDESConnectorSetup.exe as an administrator. If the setup shows a dialog that reads Microsoft
Intune NDES Connector requires HTTP Activation , ensure you started the application as an
administrator, then check HTTP Activation is enabled on the NDES server.
3. On the Microsoft Intune page, click Next .
4. Read the End User License Agreement . Click Next to accept the agreement and to proceed with the
installation.
5. On the Destination Folder page, click Next .
6. On the Installation Options page, select SCEP and PFX Profile Distribution and click Next .
7. On the Client cer tificate for Microsoft Intune page, Click Select . Select the certificate previously
enrolled for the NDES server. Click Next .
NOTE
The Client cer tificate for Microsoft Intune page does not update after selecting the client authentication
certificate. However, the application rembers the selection and shows it in the next page.
8. On the Client cer tificate for the NDES Policy Module page, verify the certificate information and
then click Next .
9. ON the Ready to install Microsoft Intune Connector page. Click Install .
NOTE
You can review the results of the install using the SetupMsi.log file located in the
C:\NDESConnectorSetupMsi folder.
10. When the installation completes, select Launch Intune Connector and click Finish. Proceed to the
Configure the Intune Certificate Connector task.
Configure the Intune Certificate Connector
1. The NDES Connector user interface should be open from the last task.
NOTE
If the NDES Connector user interface is not open, you can start it from
<install_Path>\NDESConnectorUI\NDESConnectorUI.exe .
2. If your organization uses a proxy server and the proxy is needed for the NDES server to access the
Internet, select Use proxy ser ver , and then enter the proxy server name, port, and credentials to
connect. Click Apply
3. Click Sign-in . Type credentials for your Intune administrator, or tenant administrator that has the Global
Administrator directory role.
IMPORTANT
The user account must have a valid Intune license assigned. If the user account does not have a valid Intune
license, the sign-in fails.
4. Optionally, you can configure the NDES Connector for certificate revocation. If you want to do this,
continue to the next task. Otherwise, Click Close , restart the Intune Connector Ser vice and the World
Wide Web Publishing Ser vice , and skip the next task.
Configure the NDES Connector for certificate revocation (Optional)
Optionally (not required), you can configure the Intune connector for certificate revocation when a device is
wiped, unenrolled, or when the certificate profile falls out of scope for the targeted user (users is removed,
deleted, or the profile is deleted).
Enabling the NDES Service account for revocation
Sign-in the certificate authority used by the NDES Connector with access equivalent to domain administrator.
1. Start the Cer tification Authority management console.
2. In the navigation pane, right-click the name of the certificate authority and select Proper ties .
3. Click the Security tab. Click Add . In Enter the object names to select box, type NDESSvc (or the name
you gave the NDES Service account). Click Check Names. Click OK . Select the NDES Service account from the
Group or user names list. Select Allow for the Issue and Manage Cer tificates permission. Click OK .
4. Close the Cer tification Authority

Enable the NDES Connector for certificate revocation
1. Open the NDES Connector user interface
(<install_Path>\NDESConnectorUI\NDESConnectorUI.exe ).
2. Click the Advanced tab. Select Specify a different account username and password . Type the NDES
service account username and password. Click Apply . Click OK to close the confirmation dialog box. Click
Close .
3. Restart the Intune Connector Ser vice and the World Wide Web Publishing Ser vice .
Test the NDES Connector
Sign-in the NDES server with access equivalent to domain admin.
1. Open a command prompt.
2. Type the following command to confirm the NDES Connector's last connection time is current.
reg query hklm\software\Microsoft\MicrosoftIntune\NDESConnector\ConnectionStatus
3. Close the command prompt.

4. Open Internet Explorer .
5. In the navigation bar, type:
https://[fqdnHostName]/certsrv/mscep/mscep.dll
where [fqdnHostName] is the fully qualified internal DNS host name of the NDES server. A web page
showing a 403 error (similar to the following) should appear in your web browser. If you do not see a similar
page, or you get a 503 Ser vice unavailable message, ensure the NDES Service account has the proper
user rights. You can also review the application event log for events with the
NetworkDeviceEnrollmentSerice source.
6. Using Ser ver Manager , enable Internet Explorer Enhanced Security Configuration .
Create and Assign a Simple Certificate Enrollment Protocol (SCEP)

Certificate Profile
Create an AADJ WHFB Certificate Users Group
3. Click Groups . Click New group .
4. Select Security from the Group type list.
5. Under Group Name , type the name of the group. For example, AADJ WHFB Cer tificate Users .
6. Provide a Group description , if applicable.
7. Select Assigned from the Membership type list.
8. Click Members . Use the Select members pane to add members to this group. When finished click Select .
9. Click Create .
Create a SCEP Certificate Profile
2. Select Devices , and then click Configuration Profiles .
3. Select Create Profile .
4. Select Windows 10 and later from the Platform list.

5. Choose SCEP cer tificate from the Profile list, and select Create .
6. The SCEP Cer tificate wizard should open. Next to Name , type WHFB Cer tificate Enrollment .
7. Next to Description , provide a description meaningful for your environment, then select Next .
8. Select User as a certificate type.
9. Configure Cer tificate validity period to match your organization.
IMPORTANT
Remember that you need to configure your certificate authority to allow Microsoft Intune to configure certificate
validity.
10. Select Enroll to Windows Hello for Business, other wise fail (Windows 10 and later) from the
Key storage provider (KSP) list.
11. Next to Subject name format , type CN={{OnPrem_Distinguished_Name}} to make the on-
premises distinguished name the subject of the issued certificate.
12. Specify User Principal Name (UPN) as a Subject Alternative Name parameter. Set its value as
{{UserPrincipalName}}.
13. Refer to the "Configure Certificate Templates on NDES" task for how you configured the AADJ WHFB
Authentication certificate template in the registry. Select the appropriate combination of key usages
from the Key Usages list that map to the configured NDES template in the registry. In this example, the
AADJ WHFB Authentication certificate template was added to the SignatureTemplate registry value
name. The Key usage that maps to that registry value name is Digital Signature .
14. Select a previously configured Trusted cer tificate profile that matches the root certificate of the issuing
certificate authority as a root certificate for the profile.
15. Under Extended key usage , type Smar t Card Logon under Name . Type 1.3.6.1.4.1.311.20.2.2
under Object identifier . Click Add .
16. Type a percentage (without the percent sign) next to Renewal Threshold to determine when the
certificate should attempt to renew. The recommended value is 20 .
17. Under SCEP Ser ver URLs , type the fully qualified external name of the Azure AD Application proxy you
configured. Append to the name /cer tsr v/mscep/mscep.dll . For example, https://ndes-
mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll. Click Add . Repeat this step for each additional
NDES Azure AD Application Proxy you configured to issue Windows Hello for Business certificates.
Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate
profile.
18. Click Next .
19. Click Next several times to skip the Scope tags , Assignments , and Applicability Rules steps of the
wizard and click Create .
Assign Group to the WHFB Certificate Enrollment Certificate Profile
2. Select Devices , and then click Configuration Profiles .
3. Click WHFB Cer tificate Enrollment .
4. Select Proper ties , and then click Edit next to the Assignments section.
5. In the Assignments pane, select Selected Groups from the Assign to list. Click Select groups to
include .
6. Select the AADJ WHFB Cer tificate Users group. Click Select .
7. Click Review + Save , and then Save .
You have successfully completed the configuration. Add users that need to enroll a Windows Hello for Business
authentication certificate to the AADJ WHFB Cer tificate Users group. This group, combined with the device
enrollment Windows Hello for Business configuration prompts the user to enroll for Windows Hello for
Business and enroll a certificate that can be used to authentication to on-premises resources.
Section Review
Requirements
Prepare the Network Device Enrollment Services (NDES) Service Account
Prepare Active Directory Certificate Authority
Install and Configure the NDES Role
Configure Network Device Enrollment Services to work with Microsoft Intune
Download, Install, and Configure the Intune Certificate Connector
Create and Assign a Simple Certificate Enrollment Protocol (SCEP Certificate Profile)
On Premises Key Trust Deployment
Applies to
On-premises deployment
Key trust
to successfully deploy Windows Hello for Business in an existing environment.
Below, you can find all the information you need to deploy Windows Hello for Business in a key trust model in
your on-premises environment:
1. Validate Active Directory prerequisites
2. Validate and Configure Public Key Infrastructure
3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services
4. Validate and Deploy Multifactor Authentication Services (MFA)
5. Configure Windows Hello for Business Policy settings
Validate Active Directory prerequisites
Applies to
Key trust
Key trust deployments need an adequate number of 2016 or later domain controllers to ensure successful user
authentication with Windows Hello for Business. To learn more about domain controller planning for key trust
deployments, read the Windows Hello for Business planning guide, the Planning an adequate number of
Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments section.
NOTE
The key registration process for the On-premises deployment of Windows Hello for Business needs the
Windows Server 2016 Active Directory or later schema. The key-trust model receives the schema extension
when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain
functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
Create the Windows Hello for Business Users Security Global Group
The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in
phases. You assign Group Policy permissions to this group to simplify the deployment by simply adding the
users to the group. This provides users with the proper permissions to provision Windows Hello for Business.
Sign-in a domain controller or management workstation with Domain Admin equivalent credentials.
2. Click View and click Advanced Features .
4. Right-click the Users container. Click New . Click Group .
5. Type Windows Hello for Business Users in the Group Name text box.
6. Click OK .
Follow the Windows Hello for Business on premises certificate trust

deployment guide
1. Validate Active Directory prerequisites (You are here)
Applies to
Key trust
for clients to ensure they are not communicating with a rogue domain controller.
Deploy an enterprise certificate authority

This guide assumes most enterprise have an existing public key infrastructure. Windows Hello for Business
environment.
NOTE

configuration.

Configure Domain Controller Certificates
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a
Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution
Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external
to the domain—namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an
enterprise certificate authority is added to Active Directory. However, certificates based on the Domain
Controller and Domain Controller Authentication certificate templates do not include the KDC Authentication
object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to
request a certificate based on the Kerberos Authentication certificate template.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication
certificate template. However, the cryptography configuration included in the provided template is based on
older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with
the best available cryptography, use the Kerberos Authentication certificate template as a baseline to create an
updated domain controller certificate template.
Sign-in to a certificate authority or management workstations with Domain Admin equivalent credentials.
3. In the Cer tificate Template Console , right-click the Kerberos Authentication template in the details
pane and click Duplicate Template .
2008 R2 from the Cer tification Authority list. Select Windows 7.Ser ver 2008 R2 from the
Cer tification Recipient list.
5. On the General tab, type Domain Controller Authentication (Kerberos) 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.
6. On the Subject Name tab, select the Build from this Active Director y information button if it is not
already selected. Select None from the Subject name format list. Select DNS name from the Include
this information in alternate subject list. Clear all other items.
Request hash list. Click OK .
Superseding the existing Domain Controller certificate
Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate
Services provides a default certificate template from domain controllers—the domain controller certificate
template. Later releases provided a new certificate template—the domain controller authentication certificate
template. These certificate templates were provided prior to update of the Kerberos specification that stated Key
Distribution Centers (KDCs) performing certificate authentication needed to include the KDC Authentication
extension.
The Kerberos Authentication certificate template is the most current certificate template designated for domain
controllers and should be the one you deploy to all your domain controllers (2008 or later). The autoenrollment
feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the
following configuration to replace older domain controller certificates with a new certificate using the Kerberos
Authentication certificate template.
Sign-in to a certificate authority or management workstations with Enterprise Admin equivalent credentials.
3. In the Cer tificate Template Console , right-click the Domain Controller Authentication (Kerberos)
(or the name of the certificate template you created in the previous section) template in the details pane
and click Proper ties .
4. Click the Superseded Templates tab. Click Add .
5. From the Add Superseded Template dialog, select the Domain Controller certificate template and
click OK . Click Add .
6. From the Add Superseded Template dialog, select the Domain Controller Authentication
certificate template and click OK .
7. From the Add Superseded Template dialog , select the Kerberos Authentication certificate template
and click OK .
8. Add any other enterprise certificate templates that were previously configured for domain controllers to
the Superseded Templates tab.
9. Click OK and close the Cer tificate Templates console.
The certificate template is configured to supersede all the certificate templates provided in the certificate
templates superseded templates list. However, the certificate template and the superseding of certificate
templates is not active until you publish the certificate template to one or more certificate authorities.
Configure an Internal Web Server Certificate template
Windows 10 clients use the https protocol when communicating with Active Directory Federation Services. To
meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory
Federation Services farm. On-premises deployments can use a server authentication certificate issued by their
enterprise PKI. You must configure a server authentication certificate template so the host running the Active
Directory Federation Service can request the certificate.
3. In the Cer tificate Template Console , right-click the Web Ser ver template in the details pane and click
5. On the General tab, type Internal Web Ser ver in Template display name . Adjust the validity and
renewal period to meet your enterprise’s needs.
NOTE
the lab.
6. On the Request Handling tab, select Allow private key to be expor ted .
7. On the Subject tab, select the Supply in the request button if it is not already selected.
8. On the Security tab, Click Add . Type Domain Computers in the Enter the object names to select
box. Click OK . Select the Allow check box next to the Enroll permission.
Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth
security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to
issue. This includes the pre-published certificate template from the role installation and any superseded
certificate templates.
The newly created domain controller authentication certificate template supersedes previous domain controller
certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate
authorities.
Sign-in to the certificate authority or management workstation with Enterprise Admin equivalent credentials.
4. Right-click the Domain Controller certificate template in the content pane and select Delete . Click Yes
on the Disable cer tificate templates window.
5. Repeat step 4 for the Domain Controller Authentication and Kerberos Authentication certificate
templates.
Publish Certificate Templates to the Certificate Authority
credentials.
5. In the Enable Cer tificates Templates window, select the Domain Controller Authentication
(Kerberos) , and Internal Web Ser ver templates you created in the previous steps. Click OK to publish
the selected certificate templates to the certificate authority.
6. If you published the Domain Controller Authentication (Kerberos) certificate template, then you should
unpublish the certificate templates you included in the superseded templates list.
* To unpublish a certificate template, right-click the certificate template you want to unpublish in the
details pane of the Certificate Authority console and select Delete . Click Yes to confirm the operation.
Configure Domain Controllers for Automatic Certificate Enrollment
Domain controllers automatically request a certificate from the domain controller certificate template. However,
the domain controller is unaware of newer certificate templates or superseded configurations on certificate
templates. To continue automatic enrollment and renewal of domain controller certificates that understand
newer certificate template and superseded certificate template configurations, create and configure a Group
Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
3. Right-click Group Policy object and select New
4. Type Domain Controller Auto Certificate Enrollment in the name box and click OK .
5. Right-click the Domain Controller Auto Cer tificate Enrollment Group Policy object and click Edit .
7. Expand Windows Settings , Security Settings , and click Public Key Policies .
8. In the details pane, right-click Cer tificate Ser vices Client – Auto-Enrollment and select Proper ties .
9. Select Enabled from the Configuration Model list.
10. Select the Renew expired cer tificates, update pending cer tificates, and remove revoked
cer tificates check box.
11. Select the Update cer tificates that use cer tificate templates check box.
12. Click OK . Close the Group Policy Management Editor .
Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
Sign-in to a domain controller or management workstations with Domain Admin equivalent credentials.
1. Start the Group Policy Management Console (gpmc.msc).
2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain
name. Right-click the Domain Controllers organizational unit and click Link an existing GPO… .
3. In the Select GPO dialog box, select Domain Controller Auto Cer tificate Enrollment or the name of
the domain controller certificate enrollment Group Policy object you previously created and click OK .
Validating your work
Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key
to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next
phase.
You want to confirm your domain controllers enroll the correct certificates and not any unnecessary
(superseded) certificate templates. You need to check each domain controller that autoenrollment for the
computer occurred.
Use the Event Logs
Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for
both users and computers. Using the Event Viewer, navigate to the CertificateServices-Lifecycles-System event
log under Application and Services/Microsoft/Windows.
Look for an event indicating a new certificate enrollment (autoenrollment). The details of the event include the
certificate template on which the certificate was issued. The name of the certificate template used to issue the
certificate should match the certificate template name included in the event. The certificate thumbprint and
EKUs for the certificate are also included in the event. The EKU needed for proper Windows Hello for Business
authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template.
Certificates superseded by your new domain controller certificate generate an archive event in the
CertificateServices-Lifecycles-System event. The archive event contains the certificate template name and
thumbprint of the certificate that was superseded by the new certificate.
Certificate Manager
You can use the Certificate Manager console to validate the domain controller has the properly enrolled
certificate based on the correct certificate template with the proper EKUs. Use cer tlm.msc to view certificate in
the local computers certificate stores. Expand the Personal store and view the certificates enrolled for the
computer. Archived certificates do not appear in Certificate Manager.
Certutil.exe
You can use cer tutil.exe to view enrolled certificates in the local computer. Certutil shows enrolled and archived
certificates for the local computer. From an elevated command prompt, run certutil -q -store my to view
locally enrolled certificates.
To view detailed information about each certificate in the store, use certutil -q -v -store my to validate
automatic certificate enrollment enrolled the proper certificates.
Troubleshooting
Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy
updates. You can refresh Group Policy from an elevated command prompt using gpupdate /force .
Alternatively, you can forcefully trigger automatic certificate enrollment using certreq -autoenroll -q from an
elevated command prompt.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing
certificate templates to issuing certificate authority and the allow auto enrollment permissions.
Follow the Windows Hello for Business on premises key trust

deployment guide
2. Validate and Configure Public Key Infrastructure (You are here)
Prepare and Deploy Windows Server 2016 Active
Directory Federation Services
Applies to
Key trust
Windows Hello for Business works exclusively with the Active Directory Federation Service role included with
Windows Server 2016 and requires an additional server update. The on-premises key trust deployment uses
Active Directory Federation Services roles for key registration and device registration.
The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using
the Windows Information Database as the configuration database, which is ideal for environments with no more
than 30 federation servers and no more than 100 relying party trusts.
If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay
detection, or needs Active Directory Federation Services to operate in a federated provider role, then your
deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation
Services using SQL as its configuration database, please review the Deploying a Federation Server Farm
checklist.
If your environment has an existing instance of Active Directory Federation Services, then you’ll need to
upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your
environment uses Windows Internal Database (WID) for the configuration database, please read Upgrading to
AD FS in Windows Server 2016 using a WID database to upgrade your environment. If your environment uses
SQL for the configuration database, please read Upgrading to AD FS in Windows Server 2016 with SQL Server
to upgrade your environment.
Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully
completed the upgrade.
A new Active Directory Federation Services farm should have a minimum of two federation servers for proper
load balancing, which can be accomplished with an external networking peripherals, or with using the Network
Load Balancing Role included in Windows Server.
Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server
2016 Servers. Ensure the update listed below is applied to each server before continuing.
Update Windows Server 2016

Sign-in the federation server with local admin equivalent credentials.
1. Ensure Windows Server 2016 is current by running Windows Update from Settings . Continue this
process until no further updates are needed. If you’re not using Windows Update for updates, please review
the Windows Server 2016 update history page to make sure you have the latest updates available installed.
2. Ensure the latest server updates to the federation server includes KB4088889 (14393.2155).
IMPORTANT
The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid
certificate trust deployments for domain joined computers.
Enroll for a TLS Server Authentication Certificate

Key trust Windows Hello for Business on-premises deployments need a federation server for device registration
and key registration. Typically, a federation service is an edge facing role. However, the federation services and
instance used with the on-premises deployment of Windows Hello for Business does not need Internet
connectivity.
The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate
issued by your enterprise (internal) certificate authority. The server authentication certificate should have the
following names included in the certificate if you are requesting an individual certificate for each node in the
federation farm:
Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
Subject Alternate Name: Your federation service name, such as fs.corp.contoso.com (or an appropriate
wildcard entry such as *.corp.contoso.com)
You configure your federation service name when you configure the AD FS role. You can choose any name, but
that name must be different than the name of the server or host. For example, you can name the host server
adfs and the federation service fs . The FQDN of the host is adfs.corp.contoso.com and the FQDN of the
federation service is fs.corp.contoso.com.
You can, however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject
name blank, and include all the names in the subject alternate name when creating the certificate request. All
names should include the FQDN of each host in the farm and the federation service name.
When creating a wildcard certificate, it is recommended that you mark the private key as exportable so that the
same certificate can be deployed across each federation server and web application proxy within your AD FS
farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully
requested and enrolled the server authentication certificate on one node, you can export the certificate and
private key to a PFX file using the Certificate Manager console. You can then import the certificate on the
remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all
nodes in the farm have the proper TLS server authentication certificate.
Internal Server Authentication Certificate Enrollment
Sign-in the federation server with domain administrator equivalent credentials.
6. On the Request Cer tificates page, Select the Internal Web Ser ver check box.
settings link
8. Under Subject name , select Common Name from the Type list. Type the FQDN of the computer hosting
the Active Directory Federation Services role and then click Add . Under Alternative name , select DNS from
the Type list. Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The
name you use here MUST match the name you use when configuring the Active Directory Federation
Services server role. Click Add . Click OK when finished.
9. Click Enroll .
A server authentication certificate should appear in the computer’s Personal certificate store.
Deploy the Active Directory Federation Service Role

The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello
for Business on-premises deployments.
Device registration
Key registration
IMPORTANT
Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm.
Once complete, the second server receives the configuration through the shared configuration database when it is added
the AD FS farm.
Windows Hello for Business depends on proper device registration. For on-premises key trust deployments,
Windows Server 2016 AD FS handles device and key registration.
Sign-in the federation server with Enterprise Admin equivalent credentials.
1. Start Ser ver Manager . Click Local Ser ver in the navigation pane.
2. Click Manage and then click Add Roles and Features .
3. Click Next on the Before you begin page.
4. On the Select installation type page, select Role-based or feature-based installation and click Next .
5. On the Select destination ser ver page, choose Select a ser ver from the ser ver pool . Select the
federation server from the Ser ver Pool list. Click Next .
6. On the Select ser ver roles page, select Active Director y Federation Ser vices . Click Next .
7. Click Next on the Select features page.
8. Click Next on the Active Director y Federation Ser vice page.
9. Click Install to start the role installation.
Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
Confirm the AD FS farm uses the correct database configuration.
Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated
load.
Confirm all AD FS servers in the farm have the latest updates.
Confirm all AD FS servers have a valid server authentication certificate
The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
The alternate name of the certificate contains a wildcard or the FQDN of the federation service
Device Registration Service Account Prerequisite

The service account used for the device registration server depends on the domain controllers in the
environment.
NOTE
Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is
not listed below, then it is not supported for Windows Hello for Business.
Windows Server 2012 or later Domain Controllers

Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred
way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA
have security advantages over normal user accounts because Windows handles password management. This
means the password is long, complex, and changes periodically. The best part of GMSA is all this happens
automatically. AD FS supports GMSA and should be configured using them for additional defense in depth
security.
GSMA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain
controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the
GSMA. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your
environment already uses GSMA.
Create KDS Root Key
Sign-in a domain controller with Enterprise Admin equivalent credentials.
1. Start an elevated Windows PowerShell console.
2. Type Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
Windows Server 2008 or 2008 R2 Domain Controllers
Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor
do they support Group Managed Service Accounts. Therefore, you must use create a normal user account as a
service account where you are responsible for changing the password on a regular basis.
Create an AD FS Service Account
2. Right-click the Users container, Click New . Click User .
3. In the New Object – User window, type adfssvc in the Full name text box. Type adfssvc in the User
logon name text box. Click Next .
4. Enter and confirm a password for the adfssvc user. Clear the User must change password at next logon
check box.
5. Click Next and then click Finish .
Configure the Active Directory Federation Service Role

IMPORTANT
Windows Server 2016, 2012 R2 or later Domain Controllers

Use the following procedures to configure AD FS when your environment uses Windows Ser ver 2012 or
later Domain Controllers . If you are not using Windows Server 2012 or later Domain Controllers, follow the
procedures under the Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2
Domain Controllers) section.
Sign-in the federation server with Domain Admin equivalent credentials. These procedures assume you are
configuring the first federation server in a federation server farm.
1. Start Ser ver Manager .
2. Click the notification flag in the upper right corner. Click Configure federation ser vices on this
ser ver .
3. On the Welcome page, click Create the first federation ser ver farm and click Next .
4. Click Next on the Connect to Active Director y Domain Ser vices page.
5. On the Specify Ser vice Proper ties page, select the recently enrolled or imported certificate from the
SSL Cer tificate list. The certificate is likely named after your federation service, such as
fs.corp.contoso.com or fs.contoso.com.
6. Select the federation service name from the Federation Ser vice Name list.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in.
Click Next .
8. On the Specify Ser vice Account page, select Create a Group Managed Ser vice Account . In the
Account Name box, type adfssvc .
9. On the Specify Configuration Database page, select Create a database on this ser ver using
Windows Internal Database and click Next .
10. On the Review Options page, click Next .
11. On the Pre-requisite Checks page, click Configure .
12. When the process completes, click Close .
2008 R2 Domain Controllers . If you are not using Windows Server 2008 or 2008 R2 Domain Controllers,
follow the procedures under the Configure the Active Directory Federation Service Role (Windows Server 2012
or later Domain Controllers) section.
Sign-in the federation server with Domain Admin equivalent credentials. These instructions assume you are
2. Click the notification flag in the upper right corner. Click Configure federation ser vices on this
ser ver .
5. On the Specify Ser vice Proper ties page, select the recently enrolled or imported certificate from the
SSL Cer tificate list. The certificate is likely named after your federation service, such as
fs.corp.mstepdemo.net or fs.mstepdemo.net.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in.
Click Next .
8. On the Specify Ser vice Account page, Select Use an existing domain user account or group
Managed Ser vice Account and click Select .
In the Select User or Ser vice Account dialog box, type the name of the previously created AD FS
service account (example adfssvc) and click OK . Type the password for the AD FS service account and
click Next .
13. Do not restart the AD FS server. You will do this later.
Add the AD FS Service account to the KeyAdmins group
The KeyAdmins global group provides the AD FS service with the permissions needed to perform key
registration.
2. Click the Users container in the navigation pane.
3. Right-click KeyAdmins in the details pane and click Proper ties .
4. Click the Members tab and click Add…
5. In the Enter the object names to select text box, type adfssvc . Click OK .
6. Click OK to return to Active Director y Users and Computers .
7. Change to server hosting the AD FS role and restart it.
Configure the Device Registration Service

Sign-in the federation server with Enterprise Admin equivalent credentials. These instructions assume you are
1. Open the AD FS management console.
2. In the navigation pane, expand Ser vice . Click Device Registration .
3. In the details pane, click Configure Device Registration .
4. In the Configure Device Registration dialog, click OK .
Review
Confirm you followed the correct procedures based on the domain controllers used in your deployment
Windows Server 2016, 2012 R2 or Windows Server 2012 R2
Windows Server 2008 or Windows Server 2008 R2
Confirm you have the correct service account based on your domain controller version.
Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of
your federation, the number of relying parties, and database needs.
Confirm you used a certificate with the correct names as the server authentication certificate
Record the expiration date of the certificate and set a renewal reminder at least six weeks before it
expires that includes the:
Certificate serial number
Certificate thumbprint
Common name of the certificate
Subject alternate name of the certificate
Name of the physical host server
The issued date
The expiration date
Issuing CA Vendor (if a third-party certificate)
Confirm you added the AD FS service account to the KeyAdmins group.
Confirm you enabled the Device Registration service.
Additional Federation Servers

Organizations should deploy more than one federation server in their federation farm for high-availability. You
should have a minimum of two federation services in your AD FS farm, however most organizations are likely to
have more. This largely depends on the number of devices and users using the services provided by the AD FS
farm.
Server Authentication Certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the Enroll
for a TLS Server Authentication Certificate section of this document to determine the requirements for your
server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises
deployments of Windows Hello for Business can use enterprise server authentication certificates rather than
server authentication certificates issued by public certificate authorities.
Install Additional Servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to
include Windows Server 2016 Update needed to support Windows Hello for Business deployments
(https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional
servers and then configure the server as an additional server in an existing farm.
Load Balance AD FS Federation Servers

Many environments load balance using hardware devices. Environments without hardware load-balancing
capabilities can take advantage the network load-balancing feature included in Windows Server to load balance
the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes
participating in the AD FS farm that should be load balanced.
Install Network Load Balancing Feature on AD FS Servers
3. Click Next On the Before you begin page.
6. On the Select ser ver roles page, click Next .
7. Select Network Load Balancing on the Select features page.
8. Click Install to start the feature installation
Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster.
Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with Admin equivalent credentials.
1. Open Network Load Balancing Manager from Administrative Tools .
2. Right-click Network Load Balancing Clusters , and then click New Cluster .
3. To connect to the host that is to be a part of the new cluster, in the Host text box, type the name of the host,
and then click Connect .
4. Select the interface that you want to use with the cluster, and then click Next . (The interface hosts the virtual
IP address and receives the client traffic to load balance.)
5. In Host Parameters , select a value in Priority (Unique host identifier) . This parameter specifies a unique
ID for each host. The host with the lowest numerical priority among the current members of the cluster
handles all of the cluster's network traffic that is not covered by a port rule. Click Next .
6. In Cluster IP Addresses , click Add and type the cluster IP address that is shared by every host in the
cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be
part of the cluster. Click Next .
7. In Cluster Parameters , select values in IP Address and Subnet mask (for IPv6 addresses, a subnet mask
value is not needed). Type the full Internet name that users will use to access this NLB cluster.
8. In Cluster operation mode , click Unicast to specify that a unicast media access control (MAC) address
should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the
network adapter of the computer, and the built-in MAC address of the network adapter is not used. We
recommend that you accept the unicast default settings. Click Next .
9. In Port Rules, click Edit to modify the default port rules to use port 443.
Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then click Add Host to Cluster .
2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the
additional hosts by following the same instructions that you used to configure the initial host. Because you
are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
Configure DNS for Device Registration

Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.
You’ll need the Federation service name to complete this task. You can view the federation service name by
clicking Edit Federation Ser vice Proper ties from the Action pan of the AD FS management console, or by
using (Get-AdfsProperties).Hostname. (PowerShell) on the AD FS server.
1. Open the DNS Management console.
2. In the navigation pane, expand the domain controller name node and For ward Lookup Zones .
3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
4. In the navigation pane, right-click the domain name node and click New Host (A or AAAA) .
5. In the name box, type the name of the federation service. In the IP address box, type the IP address of your
federation server. Click Add Host .
6. Right-click the domain_name node and select New Alias (CNAME) .
7. In the New Resource Record dialog box, type "enterpriseregistration" in the Alias name box.
8. In the fully qualified domain name (FQDN) of the target host box, type
federation_service_farm_name.domain_name.com , and click OK.
9. Close the DNS Management console.
NOTE
If your forest has multiple UPN suffixes, please make sure that enterpriseregistration.upnsuffix.com is present for
each suffix.
Configure the Intranet Zone to include the federation service
The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone
to include the federation service enables the user to authenticate to the federation service using integrated
authentication. Without this setting, the connection to the federation service during Windows Hello provisioning
prompts the user for authentication.
Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with Domain Admin equivalent credentials
4. Type Intranet Zone Settings in the name box and click OK .
5. In the content pane, right-click the Intranet Zone Settings Group Policy object and click Edit .
7. Expand Administrative Templates > Windows Component > Internet Explorer > Internet Control
Panel , and select Security Page .
8. In the content pane, double-click Site to Zone Assignment List . Click Enable .
9. Click Show . In the Value Name column, type the url of the federation service beginning with https. In the
Value column, type the number 1 . Click OK twice, then close the Group Policy Management Editor.
Deploy the Intranet Zone Group Policy object
name and click Link an existing GPO…
3. In the Select GPO dialog box, select Intranet Zone Settings or the name of the Windows Hello for
Business Group Policy object you previously created and click OK .
Review
Confirm all AD FS servers have a valid server authentication certificate
The alternate name of the certificate contains a wildcard or the FQDN of the federation service
load.
Confirm you restarted the AD FS service.
Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced
IP address
Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the
federation server.

deployment guide
3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (You are here)
Validate and Deploy Multi-factor Authentication
(MFA)
IMPORTANT
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to
require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication.
Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future
updates and generate activation credentials as usual.
Applies to
Key trust
Windows Hello for Business requires all users perform multi-factor authentication prior to creating and
registering a Windows Hello for Business credential. On-premises deployments can use certificates, third-party
authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA
option.
For information on available third-party authentication methods see Configure Additional Authentication
Methods for AD FS. For creating a custom authentication method see Build a Custom Authentication Method for
AD FS in Windows Server
Follow the integration and deployment guide for the authentication provider you select to integrate and deploy
it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the
AD FS authentication policy. For information on configuring AD FS authentication policies see Configure
Authentication Policies.

deployment guide
4. Validate and Deploy Multifactor Authentication Services (MFA) (You are here)
Configure Windows Hello for Business Policy
settings
Applies to
Key trust
You need a Windows 10, version 1703 workstation to run the Group Policy Management Console, which
provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group
Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You
can download these tools from Microsoft Download Center. Install the Remote Server Administration Tools for
Windows 10 on a computer running Windows 10, version 1703.
Alternatively, you can create a copy of the .ADMX and .ADML files from a Windows 10, version 1703 installation
setup template folder to their respective language folder on a Windows Server, or you can create a Group Policy
Central Store and copy them their respective language folder. See How to create and manage the Central Store
for Group Policy Administrative Templates in Windows for more information.
On-premises certificate-based deployments of Windows Hello for Business needs one Group Policy setting:
Enable Windows Hello for Business
Enable Windows Hello for Business Group Policy

The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for
Business. It can be configured for computers or users.
If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and
prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users
will be allowed and prompted to enroll for Windows Hello for Business. For these settings to be configured
using GPO, you need to download and install the latest Administrative Templates (.admx) for Windows 10.
Create the Windows Hello for Business Group Policy object

The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning
and to ensure Windows Hello for Business authentication certificates are automatically renewed.
4. Type Enable Windows Hello for Business in the name box and click OK .
5. In the content pane, right-click the Enable Windows Hello for Business Group Policy object and click Edit .
6. In the navigation pane, expand Policies under User Configuration .
7. Expand Administrative Templates > Windows Component , and select Windows Hello for Business .
8. In the content pane, double-click Use Windows Hello for Business . Click Enable and click OK .
9. Close the Group Policy Management Editor .
Configure Security in the Windows Hello for Business Group Policy
object
The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The
enables you to easily manage the users that should receive Windows Hello for Business by simply adding them
to a group. This enables you to deploy Windows Hello for Business in phases.
3. Double-click the Enable Windows Hello for Business Group Policy object.
4. In the Security Filtering section of the content pane, click Add . Type Windows Hello for Business Users or
the name of the security group you previously created and click OK .
Deploy the Windows Hello for Business Group Policy object

The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables
you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users.
However, the security group filtering ensures only the users included in the Windows Hello for Business Users
global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for
Business.
3. In the Select GPO dialog box, select Enable Windows Hello for Business or the name of the Windows
Hello for Business Group Policy object you previously created and click OK .
Just to reassure, linking the Windows Hello for Business Group Policy object to the domain ensures the
Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied
to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All
others users ignore the Group Policy object.
Other Related Group Policy settings

There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello
for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any
user that sign-in from a computer with these policy settings.
Use a hardware security device
The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however,
not all computers are able to create hardware protected credentials. When Windows Hello for Business
enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-
based credential.
You can enable and deploy the Use a hardware security device Group Policy Setting to force Windows Hello
for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of
creating a hardware protected credential do not enroll for Windows Hello for Business.
Another policy setting becomes available when you enable the Use a hardware security device Group Policy
setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted
Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0
TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization
may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To
prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you
enable the Use a hardware security device Group Policy object.
Use biometrics
Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather
than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without
sacrificing security.
The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization
may want more time before using biometrics and want to disable their use until they are ready. To not allow
users to use biometrics, configure the Use biometrics Group Policy setting to disabled and apply it to your
computers. The policy setting disabled all biometrics. Currently, Windows does not provide granular policy
setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow
fingerprint.
PIN Complexity
PIN complexity is not specific to Windows Hello for Business. Windows 10 enables users to use PINs outside of
Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when
Windows Hello for Business is not deployed.
Windows 10 provides eight PIN Complexity Group Policy settings that give you granular control over PIN
creation and management. You can deploy these policy settings to computers, where they affect all users
creating PINs on that computer; or, you can deploy these settings to users, where they affect those users
creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group
Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict
resolution is based on the last applied policy. Windows does not merge the policy settings automatically;
however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings
included are:
Require digits
Require lowercase letters
Maximum PIN length
Minimum PIN length
Expiration
History
Require special characters
Require uppercase letters
In the Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove
misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new
location of these Group Policy settings is under Administrative Templates\System\PIN Complexity under both
the Computer and User Configuration nodes of the Group Policy editor.
Review
Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10
Creators Editions)
Confirm you configured the Enable Windows Hello for Business to the scope that matches your
deployment (Computer vs. User)
Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
Confirm you configure automatic certificate enrollment to the scope that matches your deployment
(Computer vs. User)
Confirm you configured the proper security settings for the Group Policy object
Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always
have the read permissions)
Add the Windows Hello for Business Users group to the Group Policy object and gave the group the
allow permission for Apply Group Policy
Linked the Group Policy object to the correct locations within Active Directory
Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one
that enables it for users
Add users to the Windows Hello for Business Users group

Users must receive the Windows Hello for Business group policy settings and have the proper permission to
enroll for the WHFB Authentication certificate. You can provide users with these settings and permissions by
adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups that
are not members of this group will not attempt to enroll for Windows Hello for Business.

deployment guide
5. Configure Windows Hello for Business Policy settings (You are here)
On Premises Certificate Trust Deployment
Applies to
Certificate trust
to successfully deploy Windows Hello for Business in an existing environment.
Below, you can find all the information you will need to deploy Windows Hello for Business in a Certificate Trust
Model in your on-premises environment:
Validate Active Directory prerequisites
Applies to
Certificate trust
The key registration process for the On-premises deployment of Windows Hello for Business needs the
Windows Server 2016 Active Directory or later schema. The key-trust model receives the schema extension
when the first Windows Server 2016 or later domain controller is added to the forest. The certificate trust model
requires manually updating the current schema to the Windows Server 2016 or later schema. If you already
have a Windows Server 2016 or later domain controller in your forest, you can skip the Updating the Schema
and Create the KeyCredential Admins Security Global Group steps.
Manually updating Active Directory uses the command-line utility adprep.exe located at
<drive>:\suppor t\adprep on the Windows Server 2016 or later DVD or ISO. Before running adprep.exe, you
must identify the domain controller hosting the schema master role.
Discovering schema role

To locate the schema master role holder, open and command prompt and type:
Netdom query fsmo | findstr -i “schema”
The command should return the name of the domain controller where you need to adprep.exe. Update the
schema locally on the domain controller hosting the Schema master role.
Updating the Schema

Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords). During
enrollment, the public key is registered in an attribute on the user object in Active Directory. The schema update
adds this new attribute to Active Directory.
Sign-in to the domain controller hosting the schema master operational role using enterprise administrator
equivalent credentials.
1. Mount the ISO file (or insert the DVD) containing the Windows Server 2016 or later installation media.
3. Type cd /d x:\support\adprep where x is the drive letter of the DVD or mounted ISO.
4. To update the schema, type adprep /forestprep .
5. Read the Adprep Warning. Type the letter C and press Enter to update the schema.
6. Close the Command Prompt and sign-out.
Create the KeyCredential Admins Security Global Group

The Windows Server 2016 Active Directory Federation Services (AD FS) role registers the public key on the user
object during provisioning. You assign write and read permission to this group to the Active Directory attribute
to ensure the AD FS service can add and remove keys are part of its normal workflow.
Sign-in a domain controller or management workstation with domain administrator equivalent credentials.
2. Click View and click Advance Features .
5. Type KeyCredential Admins in the Group Name text box.
6. Click OK .
Create the Windows Hello for Business Users Security Global Group
The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in
phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment
by simply adding the users to the group. This provides them the proper permissions to provision Windows
Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
Sign into a domain controller or management workstation with domain administrator equivalent credentials.
2. Click View and click Advanced Features .
5. Type Windows Hello for Business Users in the Group Name text box.
6. Click OK .

deployment guide
1. Validate Active Directory prerequisites (You are here)
Applies to
Certificate trust
for clients to ensure they are not communicating with a rogue domain controller. The certificate trust model
extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user
receives a sign-in certificate.
Deploy an enterprise certificate authority

This guide assumes most enterprise have an existing public key infrastructure. Windows Hello for Business
environment.
NOTE

configuration.

Configure Domain Controller Certificates
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a
Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution
Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external
to the domain—namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an
enterprise certificate authority is added to Active Directory. However, certificates based on the Domain
Controller and Domain Controller Authentication certificate templates do not include the KDC Authentication
object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to
request a certificate based on the Kerberos Authentication certificate template.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication
certificate template. However, the cryptography configuration included in the provided template is based on
older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with
the best available cryptography, use the Kerberos Authentication certificate template as a baseline to create an
updated domain controller certificate template.
3. In the Cer tificate Templates Console , right-click the Kerberos Authentication template in the details
4. On the Compatibility tab, clear the Show resulting changes check box. Select Windows Ser ver 2008
R2 from the Cer tification Authority list. Select Windows 7.Ser ver 2008 R2 from the Cer tification
Recipient list.
5. On the General tab, type Domain Controller Authentication (Kerberos) 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.
6. On the Subject Name tab, select the Build from this Active Director y information button if it is not
already selected. Select None from the Subject name format list. Select DNS name from the Include
this information in alternate subject list. Clear all other items.
Superseding the existing Domain Controller certificate
Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate
Services provides a default certificate template from domain controllers—the domain controller certificate
template. Later releases provided a new certificate template—the domain controller authentication certificate
template. These certificate templates were provided prior to update of the Kerberos specification that stated Key
Distribution Centers (KDCs) performing certificate authentication needed to include the KDC Authentication
extension.
The Kerberos Authentication certificate template is the most current certificate template designated for domain
controllers and should be the one you deploy to all your domain controllers (2008 or later). The autoenrollment
feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the
following configuration to replace older domain controller certificates with a new certificate using the Kerberos
Authentication certificate template.
Sign-in to a certificate authority or management workstations with Enterprise Admin equivalent credentials.
3. In the Cer tificate Templates Console , right-click the Domain Controller Authentication (Kerberos)
(or the name of the certificate template you created in the previous section) template in the details pane and
click Proper ties .
4. Click the Superseded Templates tab. Click Add .
5. From the Add Superseded Template dialog, select the Domain Controller certificate template and click
OK . Click Add .
6. From the Add Superseded Template dialog, select the Domain Controller Authentication certificate
template and click OK . Click Add .
7. From the Add Superseded Template dialog, select the Kerberos Authentication certificate template and
click OK . Click Add .
8. Add any other enterprise certificate templates that were previously configured for domain controllers to the
Superseded Templates tab.
9. Click OK and close the Cer tificate Templates console.
The certificate template is configured to supersede all the certificate templates provided in the certificate
templates superseded templates list. However, the certificate template and the superseding of certificate
templates is not active until you publish the certificate template to one or more certificate authorities.
Configure an Internal Web Server Certificate template
Windows 10 clients use the https protocol when communicating with Active Directory Federation Services. To
meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory
Federation Services farm. On-premises deployments can use a server authentication certificate issued by their
enterprise PKI. You must configure a server authentication certificate template so the host running the Active
Directory Federation Service can request the certificate.
3. In the Cer tificate Templates Console , right-click the Web Ser ver template in the details pane and click
or Windows Ser ver 2012 R2 from the Cer tification Authority list. Select Windows Ser ver 2012 or
Windows Ser ver 2012 R2 from the Cer tification Recipient list.
5. On the General tab, type Internal Web Ser ver in Template display name . Adjust the validity and
Note: If you use different template names, you’ll need to remember and substitute these names in different
portions of the lab.
6. On the Request Handling tab, select Allow private key to be expor ted .
7. On the Subject Name tab, select the Supply in the request button if it is not already selected.
8. On the Security tab, Click Add . Type Domain Computers in the Enter the object names to select box.
Click OK . Select the Allow check box next to the Enroll permission.
Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth
security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to
issue. This includes the pre-published certificate template from the role installation and any superseded
certificate templates.
The newly created domain controller authentication certificate template supersedes previous domain controller
certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate
authorities.
Sign-in to the certificate authority or management workstation with Enterprise Admin equivalent credentials.
4. Right-click the Domain Controller certificate template in the content pane and select Delete . Click Yes on
the Disable cer tificate templates window.
5. Repeat step 4 for the Domain Controller Authentication and Kerberos Authentication certificate
templates.
Publish Certificate Templates to the Certificate Authority
Sign-in to the certificate authority or management workstations with an enterprise administrator equivalent
credentials.
5. In the Enable Cer tificates Templates window, select the Domain Controller Authentication
(Kerberos) , and Internal Web Ser ver templates you created in the previous steps. Click OK to publish the
selected certificate templates to the certificate authority.
6. If you published the Domain Controller Authentication (Kerberos) certificate template, then you should
unpublish the certificate templates you included in the superseded templates list.
To unpublish a certificate template, right-click the certificate template you want to unpublish in the
details pane of the Certificate Authority console and select Delete . Click Yes to confirm the operation.
Configure Domain Controllers for Automatic Certificate Enrollment
Domain controllers automatically request a certificate from the domain controller certificate template. However,
the domain controller is unaware of newer certificate templates or superseded configurations on certificate
templates. To continue automatic enrollment and renewal of domain controller certificates that understand
newer certificate template and superseded certificate template configurations, create and configure a Group
Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
4. Type Domain Controller Auto Certificate Enrollment in the name box and click OK .
5. Right-click the Domain Controller Auto Cer tificate Enrollment Group Policy object and click Edit .
7. Expand Windows Settings , Security Settings , and click Public Key Policies .
10. Select the Renew expired cer tificates, update pending cer tificates, and remove revoked
Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
Sign-in to a domain controller or management workstations with Domain Admin equivalent credentials.
2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain
name. Right-click the Domain Controllers organizational unit and click Link an existing GPO…
3. In the Select GPO dialog box, select Domain Controller Auto Cer tificate Enrollment or the name of
the domain controller certificate enrollment Group Policy object you previously created and click OK .
Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key
to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next
phase.
You want to confirm your domain controllers enroll the correct certificates and not any unnecessary
(superseded) certificate templates. You need to check each domain controller that autoenrollment for the
computer occurred.
Use the Event Logs
Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for
both users and computers. Using the Event Viewer, navigate to the Cer tificateSer vicesClient-Lifecycle-
System event log under Application and Ser vices/Microsoft/Windows .
Look for an event indicating a new certificate enrollment (autoenrollment). The details of the event include the
certificate template on which the certificate was issued. The name of the certificate template used to issue the
certificate should match the certificate template name included in the event. The certificate thumbprint and
EKUs for the certificate are also included in the event. The EKU needed for proper Windows Hello for Business
authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template.
Certificates superseded by your new domain controller certificate generate an archive event in the
CertificateServicesClient-Lifecycle-System event. The archive event contains the certificate template name and
thumbprint of the certificate that was superseded by the new certificate.
Certificate Manager
You can use the Certificate Manager console to validate the domain controller has the properly enrolled
certificate based on the correct certificate template with the proper EKUs. Use cer tlm.msc to view certificate in
the local computers certificate stores. Expand the Personal store and view the certificates enrolled for the
computer. Archived certificates do not appear in Certificate Manager.
Certutil.exe
You can use cer tutil.exe to view enrolled certificates in the local computer. Certutil shows enrolled and archived
certificates for the local computer. From an elevated command prompt, run certutil -q -store my to view
locally enrolled certificates.
To view detailed information about each certificate in the store, use certutil -q -v -store my to validate
automatic certificate enrollment enrolled the proper certificates.
Troubleshooting
Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy
updates. You can refresh Group Policy from an elevated command prompt using gpupdate /force .
Alternatively, you can forcefully trigger automatic certificate enrollment using certreq -autoenroll -q from an
elevated command prompt.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing
certificate templates to issuing certificate authority and the allow auto enrollment permissions.

deployment guide
2. Validate and Configure Public Key Infrastructure (You are here)
Prepare and Deploy Windows Server 2016 Active
Directory Federation Services
Applies to
Certificate trust
Windows Hello for Business works exclusively with the Active Directory Federation Service role included with
Windows Server 2016 and requires an additional server update. The on-premises certificate trust deployment
uses Active Directory Federation Services roles for key registration, device registration, and as a certificate
registration authority.
The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using
the Windows Information Database as the configuration database, which is ideal for environments with no more
than 30 federation servers and no more than 100 relying party trusts.
If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay
detection, or needs Active Directory Federation Services to operate in a federated provider role, then your
deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation
Services using SQL as its configuration database, please review the Deploying a Federation Server Farm
checklist.
If your environment has an existing instance of Active Directory Federation Services, then you’ll need to
upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your
environment uses Windows Internal Database (WID) for the configuration database, please read Upgrading to
AD FS in Windows Server 2016 using a WID database to upgrade your environment. If your environment uses
SQL for the configuration database, please read Upgrading to AD FS in Windows Server 2016 with SQL Server
to upgrade your environment.
Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully
completed the upgrade.
A new Active Directory Federation Services farm should have a minimum of two federation servers for proper
load balancing, which can be accomplished with an external networking peripherals, or with using the Network
Load Balancing Role included in Windows Server.
Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server
2016 Servers. Ensure the update listed below is applied to each server before continuing.
NOTE
For AD FS 2019, if Windows Hello for Business with a Hybrid Certificate trust is performed, a known PRT issue exists. You
may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to
access the resource with scope 'ugs'. To remediate this error:
1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
2. Right click "Scope Descriptions" and select "Add Scope Description".
3. Under name type "ugs" and Click Apply > OK.
4. Launch PowerShell as an administrator.
5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to "38aa3b87-
a06d-4817-b275-7a316988d93b":
(Get-AdfsApplicationPermission -ServerRoleIdentifiers
'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq
'38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
6. Execute the command

Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' .
7. Restart the AD FS service.
8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
Update Windows Server 2016

Sign-in the federation server with local admin equivalent credentials.
1. Ensure Windows Server 2016 is current by running Windows Update from Settings . Continue this
process until no further updates are needed. If you’re not using Windows Update for updates, please advise
the Windows Server 2016 update history page to make sure you have the latest updates available installed.
2. Ensure the latest server updates to the federation server includes KB4088889 (14393.2155).
IMPORTANT
The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid
certificate trust deployments for domain joined computers.
Enroll for a TLS Server Authentication Certificate

Windows Hello for Business on-premises deployments require a federation server for device registration, key
registration, and authentication certificate enrollment. Typically, a federation service is an edge facing role.
However, the federation services and instance used with the on-premises deployment of Windows Hello for
Business does not need Internet connectivity.
The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate
issued by your enterprise (internal) certificate authority. The server authentication certificate should have the
following names included in the certificate if you are requesting an individual certificate for each node in the
federation farm:
Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
Subject Alternate Name: Your federation service name, such as fs.corp.contoso.com (or an appropriate
wildcard entry such as *.corp.contoso.com)
Subject Alternate Name: Your device registration service name, such as enterpriseregistration.contoso.com
You configure your federation service name when you configure the AD FS role. You can choose any name, but
that name must be different than the name of the server or host. For example, you can name the host server
adfs and the federation service fs . The FQDN of the host is adfs.corp.contoso.com and the FQDN of the
federation service is fs.corp.contoso.com.
You can; however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject
name blank, and include all the names in the subject alternate name when creating the certificate request. All
names should include the FQDN of each host in the farm and the federation service name.
It’s recommended that you mark the private key as exportable so that the same certificate can be deployed
across each federation server and web application proxy within your AD FS farm. Note that the certificate must
be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server
authentication certificate on one node, you can export the certificate and private key to a PFX file using the
Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all
nodes in the farm have the proper TLS server authentication certificate.
Internal Web Server Authentication Certificate Enrollment
Sign-in the federation server with domain administrator equivalent credentials.
6. On the Request Cer tificates page, Select the Internal Web Ser ver check box.
settings link
8. Under Subject name , select Common Name from the Type list. Type the FQDN of the computer hosting
the Active Directory Federation Services role and then click Add .
9. Under Alternative name , select DNS from the Type list. Type the FQDN of the name you will use for your
federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when
configuring the Active Directory Federation Services server role. Click Add . Repeat the same to add device
registration service name (enterpriseregistration.contoso.com) as another alternative name. Click OK when
finished.
10. Click Enroll .
A server authentication certificate should appear in the computer’s Personal certificate store.
Deploy the Active Directory Federation Service Role

The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello
for Business on-premises deployments:
Device registration
Key registration
Certificate registration authority (certificate trust deployments)
IMPORTANT
Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm.
Once complete, the second server receives the configuration through the shared configuration database when it is added
the AD FS farm.
Windows Hello for Business depends on proper device registration. For on-premises deployments, Windows
Server 2016 AD FS handles device registration.
3. Click Next on the Before you begin page.
6. On the Select ser ver roles page, select Active Director y Federation Ser vices . Click Next .
7. Click Next on the Select features page.
8. Click Next on the Active Director y Federation Ser vice page.
9. Click Install to start the role installation.
Review
Confirm the AD FS farm uses the correct database configuration.
load.
Confirm all AD FS servers have a valid server authentication certificate.
The alternate name of the certificate contains a wildcard or the FQDN of the federation service.
Device Registration Service Account Prerequisite
The service account used for the device registration server depends on the domain controllers in the
environment.
NOTE

Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred
way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA
have security advantages over normal user accounts because Windows handles password management. This
means the password is long, complex, and changes periodically. The best part of GMSA is all this happens
automatically. AD FS supports GMSA and should be configured using them for additional defense in depth
security.
GMSA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain
controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the
GMSA. Before you can create a GMSA, you must first create a root key for the service. You can skip this if your
environment already uses GMSA.
NOTE
If the default object creation quota for security principles is set, you will need to change it for the Group Managed Service
Account in order to be able to register new devices.
Create KDS Root Key

Sign-in a domain controller with Enterprise Admin equivalent credentials.
1. Start an elevated Windows PowerShell console.
2. Type Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) .
Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor
do they support Group Managed Service Accounts. Therefore, you must use create a normal user account as a
service account where you are responsible for changing the password on a regular basis.
Create an AD FS Service Account
2. Right-click the Users container, Click New . Click User .
3. In the New Object – User window, type adfssvc in the Full name text box. Type adfssvc in the User
logon name text box. Click Next .
4. Enter and confirm a password for the adfssvc user. Clear the User must change password at next logon
check box.
5. Click Next and then click Finish .
Configure the Active Directory Federation Service Role

IMPORTANT

later Domain Controllers . If you are not using Windows Server 2012 or later Domain Controllers, follow the
procedures under the Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2
Domain Controllers) section.
Sign-in the federation server with domain administrator equivalent credentials. These procedures assume you
are configuring the first federation server in a federation server farm.
2. Click the notification flag in the upper right corner. Click Configure federation ser vices on this ser ver .
5. On the Specify Ser vice Proper ties page, select the recently enrolled or imported certificate from the SSL
Cer tificate list. The certificate is likely named after your federation service, such as fs.corp.contoso.com or
fs.contoso.com.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click
Next .
8. On the Specify Ser vice Account page, select Create a Group Managed Ser vice Account . In the
Account Name box, type adfssvc .
2008 R2 Domain Controllers . If you are not using Windows Server 2008 or 2008 R2 Domain Controllers,
follow the procedures under the Configure the Active Directory Federation Service Role (Windows Server 2012
or later Domain Controllers) section.
Sign-in the federation server with domain administrator equivalent credentials. These instructions assume you
are configuring the first federation server in a federation server farm.
2. Click the notification flag in the upper right corner. Click Configure federation ser vices on this ser ver .
5. On the Specify Ser vice Proper ties page, select the recently enrolled or imported certificate from the SSL
Cer tificate list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net
or fs.mstepdemo.net.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click
Next .
8. On the Specify Ser vice Account page, Select Use an existing domain user account or group
Managed Ser vice Account and click Select . In the Select User or Ser vice Account dialog box, type the
name of the previously created AD FS service account (example adfssvc) and click OK . Type the password for
the AD FS service account and click Next .
13. Do not restart the AD FS server. You will do this later.
Add the AD FS Service account to the KeyCredential Admin group and the Windows Hello for Business
Users group
NOTE
If you have a Windows Server 2016 domain controller in your domain, you can use the Key Admins group instead of
KeyCredential Administrators and skip the Configure Permissions for Key Registration step.
The KeyCredential Administrators global group provides the AD FS service with the permissions needed to
perform key registration. The Windows Hello for Business 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.
2. Click the Users container in the navigation pane.
3. Right-click KeyCredential Admins in the details pane and click Proper ties .
7. Right-click Windows Hello for Business Users group
11. Change to server hosting the AD FS role and restart it.
Configure Permissions for Key Registration
Key Registration stores the Windows Hello for Business public key in Active Directory. With on-premises
deployments, the Windows Server 2016 AD FS server registers the public key with the on-premises Active
Directory.
The key-trust model needs Windows Server 2016 domain controllers, which configures the key registration
permissions automatically; however, the certificate-trust model does not and requires you to add the
permissions manually.
Sign-in a domain controller or management workstations with Domain Admin equivalent credentials.
2. Right-click your domain name from the navigation pane and click Proper ties .
3. Click Security (if the Security tab is missing, turn on Advanced Features from the View menu).
4. Click Advanced . Click Add . Click Select a principal .
5. The Select User, Computer, Ser vice Account, or Group dialog box appears. In the Enter the object
name to select text box, type KeyCredential Admins . Click OK .
6. In the Applies to list box, select Descendant User objects .
7. Using the scroll bar, scroll to the bottom of the page and click Clear all .
8. In the Proper ties section, select Read msDS-KeyCredentialLink and Write msDS-
KeyCrendentialLink .
9. Click OK three times to complete the task.
Configure the Device Registration Service

Sign-in the federation server with Enterprise Admin equivalent credentials. These instructions assume you are
1. Open the AD FS management console.
2. In the navigation pane, expand Ser vice . Click Device Registration .
3. In the details pane, click Configure Device Registration .
4. In the Configure Device Registration dialog, click OK .
Review
Confirm you followed the correct procedures based on the domain controllers used in your deployment.
Confirm you have the correct service account based on your domain controller version.
Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of
your federation, the number of relying parties, and database needs.
Confirm you used a certificate with the correct names as the server authentication certificate.
Record the expiration date of the certificate and set a renewal reminder at least six weeks before it
expires that includes the:
Certificate serial number
Certificate thumbprint
Common name of the certificate
Subject alternate name of the certificate
Name of the physical host server
The issued date
The expiration date
Issuing CA Vendor (if a third-party certificate)
Confirm you granted the AD FS service allow read and write permissions to the ms-DSKeyCredentialLink
Active Directory attribute.
Confirm you enabled the Device Registration service.
Prepare and Deploy AD FS Registration Authority

A registration authority is a trusted authority that validates certificate request. Once it validates the request, it
presents the request to the certificate authority for issuance. The certificate authority issues the certificate,
returns it to the registration authority, which returns the certificate to the requesting user. The Windows Hello
for Business on-premises certificate-based deployment uses the Active Directory Federation Server (AD FS) as
the certificate registration authority.
Configure Registration Authority template
The certificate registration authority enrolls for an enrollment agent certificate. 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 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
certificate authority only issues a certificate for that template if the registration authority signs the certificate
request.
The registration authority template you configure depends on the AD FS service configuration, which depends
on the domain controllers the environment uses for authentication.
IMPORTANT
Windows 2012 or later domain controllers

Sign-in a certificate authority or management workstations with domain administrator equivalent credentials.
1. Open the Cer tificate Authority Management console.
3. In the Cer tificate Template Console , right click on the Exchange Enrollment Agent (Offline
request) template details pane and click Duplicate Template .
5. On the General tab, type WHFB Enrollment Agent in Template display name . Adjust the validity
and renewal period to meet your enterprise’s needs.
6. On the Subject tab, select the Supply in the request button if it is not already selected.
NOTE
The preceding step is very important. Group Managed Service Accounts (GMSA) do not support the Build from
this Active Directory information option and will result in the AD FS server failing to enroll the enrollment agent
certificate. You must configure the certificate template with Supply in the request to ensure that AD FS servers can
perform the automatic enrollment and renewal of the enrollment agent certificate.
Request hash list.
8. On the Security tab, click Add .
9. Click Object Types . Select the Ser vice Accounts check box and click OK .
10. Type adfssvc in the Enter the object names to select text box and click OK .
11. Click the adfssvc from the Group or users names list. In the Permissions for adfssvc section, In the
Permissions for adfssvc section, select the Allow check box for the Enroll permission. Excluding the
adfssvc user, 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 are not already cleared. Click OK .
Windows 2008 or 2008R2 domain controllers
Sign-in a certificate authority or management workstations with Domain Admin equivalent credentials.
3. In the Cer tificate Template console, right-click the Exchange Enrollment Agent template in the details
5. On the General tab, type WHFB Enrollment Agent in Template display name . Adjust the validity and
6. On the Subject tab, select the Build from this Active Director y information button if it is not already
selected. Select Fully distinguished name from the Subject name format list if Fully distinguished
name is not already selected. Select the User Principal Name (UPN) check box under Include this
information in alternative subject name .
Request hash list.
8. On the Security tab, click Add . Type adfssvc in the Enter the object names to select text box and click
OK .
9. Click the adfssvc from the Group or users names list. In the Permissions for adfssvc section, select the
Allow check box for the Enroll permission. Excluding the adfssvc user, clear the Allow check boxes for the
Enroll and Autoenroll permissions for all other items in the Group or users names list if the check boxes
are not already cleared. Click OK .
Configure the Windows Hello for Business Authentication Certificate template
During Windows Hello for Business provisioning, the Windows 10, version 1703 client requests an
authentication certificate from the Active Directory Federation Service, which requests the authentication
certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate
template. You use the name of the certificate template when configuring.
Sign-in a certificate authority or management workstations with domain administrator equivalent credentials.
3. Right-click the Smar tcard Logon template and choose Duplicate Template .
5. On the General tab, type WHFB Authentication in Template display name . Adjust the validity and
NOTE
the deployment.
Request hash list.
8. On the Issuance Requirements tab, select the This number of authorized signatures check box. Type 1
in the text box. Select Application policy from the Policy type required in signature . Select Cer tificate
Request Agent from in the Application policy list. Select the Valid existing cer tificate option.
9. On the Subject tab, select the Build from this Active Director y information button if it is not already
selected. Select Fully distinguished name from the Subject name format list if Fully distinguished
name is not already selected. Select the User Principal Name (UPN) check box under Include this
information in alternative subject name .
10. On the Request Handling tab, select the Renew with same key check box.
11. On the Security tab, click Add . Type Window Hello for Business Users in the Enter the object names
to select text box and click OK .
12. Click the Windows Hello for Business Users from the Group or users names list. In the Permissions
for Windows Hello for Business Users section, select the Allow check box for the Enroll permission.
Excluding the Windows Hello for Business Users group, 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 are
not already cleared. Click OK .
13. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are
switching to an AD FS registration authority, then on the Superseded Templates tab, add the previously
used Windows Hello for Business Authentication template(s), so they will be superseded by this
template for the users that have Enroll permission for this template.
14. Click on the Apply to save changes and close the console.
Mark the template as the Windows Hello Sign-in template
Sign-in to an AD FS Windows Ser ver 2016 computer with enterprise administrator equivalent credentials.
2. Run certutil –dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY .
NOTE
If you gave your Windows Hello for Business Authentication certificate template a different name, then replace
WHFBAuthentication in the above command with the name of your certificate template. It’s important that you use
the template name rather than the template display name. You can view the template name on the General tab of the
certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template
name using the Get-CATemplate ADCS Administration Windows PowerShell cmdlet on our Windows Server 2012 or
later certificate authority.
Publish Enrollment Agent and Windows Hello For Business Authentication templates to the Certificate
Authority
Sign-in a certificate authority or management workstations with Enterprise Admin equivalent credentials.
4. Right-click the Cer tificate Templates node. Click New , and click Cer tificate Template to issue .
5. In the Enable Cer tificates Templates window, select the WHFB Enrollment Agent template you created
in the previous steps. Click OK to publish the selected certificate templates to the certificate authority.
6. Publish the WHFB Authentication certificate template using step 5.
Configure the Registration Authority
Sign-in the AD FS server with domain administrator equivalent credentials.
1. Open a Windows PowerShell prompt.
2. Type the following command
Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent
-WindowsHelloCertificateTemplate WHFBAuthentication
NOTE
If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication
certificate templates different names, then replace WHFBEnrollmentAgent and WHFBAuthentication in the
above command with the name of your certificate templates. It’s important that you use the template name
rather than the template display name. You can view the template name on the General tab of the certificate
template using the Cer tificate Template management console (certtmpl.msc). Or, you can view the template
name using the Get-CATemplate ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012
or later certificate authority.
Enrollment Agent Certificate Enrollment

Active Directory Federation Server used for Windows Hello for Business certificate enrollment perform their
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.
Service Connection Point (SCP) in Active Directory for ADFS Device Registration Service
NOTE
Normally this script is not needed, as enabling Device Registration via the ADFS Management console already creates the
objects. You can validate the SCP using the script below. For detailed information about the Device Registration Service,
see Configuring Device Registration.
Now you will add the Service connection Point to ADFS device registration Service for your Active directory by
running the following script:
TIP
Make sure to change the $enrollmentService and $configNC variables before running the script.
# Replace this with your Device Registration Service endpoint

$enrollmentService = "enterpriseregistration.contoso.com"
# Replace this with your Active Directory configuration naming context
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=org"
$de = New-Object System.DirectoryServices.DirectoryEntry

$de.Path = "LDAP://CN=Device Registration Configuration,CN=Services," + $configNC
$deSCP = $de.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")

$deSCP.Properties["keywords"].Add("enterpriseDrsName:" + $enrollmentService)
$deSCP.CommitChanges()
NOTE
You can save the modified script in notepad and save them as "add-scpadfs.ps1" and the way to run it is just navigating
into the script path folder and running .\add-scpAdfs.ps1.
Additional Federation Servers

Organizations should deploy more than one federation server in their federation farm for high-availability. You
should have a minimum of two federation services in your AD FS farm, however most organizations are likely to
have more. This largely depends on the number of devices and users using the services provided by the AD FS
farm.
Server Authentication Certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the Enroll
for a TLS Server Authentication Certificate section of this document to determine the requirements for your
server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises
deployments of Windows Hello for Business can use enterprise server authentication certificates rather than
server authentication certificates issued by public certificate authorities.
Install Additional Servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to
include Windows Server 2016 Update needed to support Windows Hello for Business deployments
(https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional
servers and then configure the server as an additional server in an existing farm.
Load Balance AD FS Federation Servers

Many environments load balance using hardware devices. Environments without hardware load-balancing
capabilities can take advantage the network load-balancing feature included in Windows Server to load balance
the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes
participating in the AD FS farm that should be load balanced.
Install Network Load Balancing Feature on AD FS Servers
3. Click Next On the Before you begin page.
6. On the Select ser ver roles page, click Next .
7. Select Network Load Balancing on the Select features page.
8. Click Install to start the feature installation.
Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster.
Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with Admin equivalent credentials.
1. Open Network Load Balancing Manager from Administrative Tools .
2. Right-click Network Load Balancing Clusters , and then click New Cluster .
3. To connect to the host that is to be a part of the new cluster, in the Host text box, type the name of the host,
and then click Connect .
4. Select the interface that you want to use with the cluster, and then click Next . (The interface hosts the virtual
IP address and receives the client traffic to load balance.)
5. In Host Parameters , select a value in Priority (Unique host identifier) . This parameter specifies a unique
ID for each host. The host with the lowest numerical priority among the current members of the cluster
handles all of the cluster's network traffic that is not covered by a port rule. Click Next .
6. In Cluster IP Addresses , click Add and type the cluster IP address that is shared by every host in the
cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be
part of the cluster. Click Next .
7. In Cluster Parameters , select values in IP Address and Subnet mask (for IPv6 addresses, a subnet mask
value is not needed). Type the full Internet name that users will use to access this NLB cluster.
8. In Cluster operation mode , click Unicast to specify that a unicast media access control (MAC) address
should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the
network adapter of the computer, and the built-in MAC address of the network adapter is not used. We
recommend that you accept the unicast default settings. Click Next .
9. In Port Rules, click Edit to modify the default port rules to use port 443.
Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then click Add Host to Cluster .
2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the
additional hosts by following the same instructions that you used to configure the initial host. Because you
are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
Configure DNS for Device Registration

Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.
You’ll need the Federation service name to complete this task. You can view the federation service name by
clicking Edit Federation Ser vice Proper ties from the Action pan of the AD FS management console, or by
using (Get-AdfsProperties).Hostname. (PowerShell) on the AD FS server.
1. Open the DNS Management console.
2. In the navigation pane, expand the domain controller name node and For ward Lookup Zones .
3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
4. In the navigation pane, right-click the domain name node and click New Host (A or AAAA) .
5. In the name box, type the name of the federation service. In the IP address box, type the IP address of your
federation server. Click Add Host .
6. Close the DNS Management console.
Configure the Intranet Zone to include the federation service

The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone
to include the federation service enables the user to authenticate to the federation service using integrated
authentication. Without this setting, the connection to the federation service during Windows Hello provisioning
prompts the user for authentication.
Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with Domain Admin equivalent credentials:
4. Type Intranet Zone Settings in the name box and click OK .
5. In the content pane, right-click the Intranet Zone Settings Group Policy object and click Edit .
7. Expand Administrative Templates > Windows Component > Internet Explorer > Internet Control
Panel , and select Security Page .
8. In the content pane, double-click Site to Zone Assignment List . Click Enable .
9. Click Show . In the Value Name column, type the url of the federation service beginning with https. In the
Value column, type the number 1 . Click OK twice, then close the Group Policy Management Editor.
Deploy the Intranet Zone Group Policy object
3. In the Select GPO dialog box, select Intranet Zone Settings or the name of the Windows Hello for
Business Group Policy object you previously created and click OK .
Review
Confirm you configured the correct enrollment agent certificate template based on the type of AD FS service
account.
Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate
template.
Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and
quantity of signature operations the enrollment agent server makes and understand the impact it has on
overall performance.
Confirm you properly configured the Windows Hello for Business authentication certificate template—to
include:
Issuance requirements of an authorized signature from a certificate request agent.
The certificate template was properly marked as a Windows Hello for Business certificate template
using certutil.exe.
The Windows Hello for Business Users group, or equivalent has the allow enroll permissions.
Confirm all certificate templates were properly published to the appropriate issuing certificate authorities.
Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business
authentication certificate template.
Confirm the AD FS certificate registration authority is properly configured using the
Get-AdfsCertificateAuthority Windows PowerShell cmdlet.
Confirm you restarted the AD FS service.
Confirm you properly configured load-balancing (hardware or software).
Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced
IP address
Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the
federation server.

You need to verify the AD FS service has properly enrolled for an enrollment agent certificate template. You can
verify this is a variety ways, depending on if your service account is a normal user account or if the service
account is a group managed service account.
IMPORTANT
After following the previous steps, if you are unable to validate that the devices are, in fact, being registered automatically,
there is a Group Policy at: Computer Configuration > Policies > Administrative Templates > Windows
Components > Device Registration > "Register Domain Joined Computers As Devices". Set the policy to Enabled
and the registration will happen automatically.
Event Logs
Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent
certificate. First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished. Once
confirmed the AD FS certificate enrollment cycle completed review the CertificateLifecycle-User event log. In this
event log, look for event ID 1006, which indicates a new certificate was installed. Details of the event log should
show:
The account name under which the certificate was enrolled.
The action, which should read enroll.
The thumbprint of the certificate
The certificate template used to issue the certificate.
Normal Service Account
When using a normal service account, use the Microsoft Management Console (mmc.exe) and load the
Certificate Manager snap-in for the service account and verify.
Group Managed Service Account
You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use
the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the
details of the certificate now shown in the event log.
Group managed service accounts use user profiles to store user information, which included enrolled
certificates. On the AD FS server, use a command prompt and navigate to
%systemdrive%\users\<adfsGMSA_name>\appdata\roaming\Microsoft\systemcertificates\my\certificates .
Each file in this folder represents a certificate in the service account’s Personal store (You may need to use DIR
/A to view the files in the folder). Match the thumbprint of the certificate from the event log to one of the files in
this folder. That file is the certificate. Use the Certutil -q <certificateThumbprintFileName> to view the basic
information about the certificate.
For detailed information about the certificate, use Certutil -q -v <certificateThumbprintFileName> .

deployment guide
3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (You are here)
Validate and Deploy Multi-factor Authentication
(MFA)
Applies to
Certificate trust
Windows Hello for Business requires all users perform multi-factor authentication prior to creating and
registering a Windows Hello for Business credential. On-premises deployments can use certificates, third-party
authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA
option.
For information on available third-party authentication methods see Configure Additional Authentication
Methods for AD FS. For creating a custom authentication method see Build a Custom Authentication Method for
AD FS in Windows Server
Follow the integration and deployment guide for the authentication provider you select to integrate and deploy
it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the
AD FS authentication policy. For information on configuring AD FS authentication policies see Configure
Authentication Policies.

deployment guide
4. Validate and Deploy Multifactor Authentication Services (MFA) (You are here)
Configure Windows Hello for Business Policy
settings
Applies to
Certificate trust
provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group
Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You
can download these tools from the Microsoft Download Center. Install the Remote Server Administration Tools
for Windows 10 on a computer running Windows 10, version 1703.
On-premises certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
Enable Windows Hello for Business
Use certificate for on-premises authentication
Enable automatic enrollment of certificates
Enable Windows Hello for Business Group Policy

The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for
Business. It can be configured for computers or users.
If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and
prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users
will be allowed and prompted to enroll for Windows Hello for Business .
Use certificate for on-premises authentication

The Use certificate for on-premises authentication Group Policy setting determines if the on-premises
deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this
Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate.
If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises
authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the
Windows Hello for Business key-trust authentication requests.
You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers
results in ALL users requesting a Windows Hello for Business authentication certificate. Deploying this policy
setting to a user results in only that user requesting a Windows Hello for Business authentication certificate.
Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello
for Business authentication certificate. If both user and computer policy settings are deployed, the user policy
setting has precedence.
Enable automatic enrollment of certificates

Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business
authentication certificate. This certificate expires based on the duration configured in the Windows Hello for
Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was
updated to renew these certificates before they expire, which significantly reduces user authentication failures
from expired user certificates.
The process requires no user interaction provided the user signs-in using Windows Hello for Business. The
certificate is renewed in the background before it expires.
Create the Windows Hello for Business Group Policy object

4. Type Enable Windows Hello for Business in the name box and click OK .
5. In the content pane, right-click the Enable Windows Hello for Business Group Policy object and click Edit .
7. Expand Administrative Templates > Windows Component , and select Windows Hello for Business .
8. In the content pane, double-click Use Windows Hello for Business . Click Enable and click OK .
9. Double-click Use cer tificate for on-premises authentication . Click Enable and click OK . Close the
Group Policy Management Editor .
Configure Automatic Certificate Enrollment

3. Right-click the Enable Windows Hello for Business Group Policy object and click Edit .
5. Expand Windows Settings > Security Settings , and click Public Key Policies .
8. Select the Renew expired cer tificates , update pending cer tificates , and remove revoked
Configure Security in the Windows Hello for Business Group Policy

object
The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The
enables you to easily manage the users that should receive Windows Hello for Business by simply adding them
to a group. This enables you to deploy Windows Hello for Business in phases.
3. Double-click the Enable Windows Hello for Business Group Policy object.
4. In the Security Filtering section of the content pane, click Add . Type Windows Hello for Business Users or
the name of the security group you previously created and click OK .
Deploy the Windows Hello for Business Group Policy object

The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables
you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users.
However, the security group filtering ensures only the users included in the Windows Hello for Business Users
global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for
Business.
3. In the Select GPO dialog box, select Enable Windows Hello for Business or the name of the Windows
Hello for Business Group Policy object you previously created and click OK .
Just to reassure, linking the Windows Hello for Business Group Policy object to the domain ensures the
Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied
to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All
others users ignore the Group Policy object.
Other Related Group Policy settings

There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello
for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any
user that sign-in from a computer with these policy settings.
Use a hardware security device
The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however,
not all computers are able to create hardware protected credentials. When Windows Hello for Business
enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-
based credential.
You can enable and deploy the Use a hardware security device Group Policy Setting to force Windows Hello
for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of
creating a hardware protected credential do not enroll for Windows Hello for Business.
Another policy setting becomes available when you enable the Use a hardware security device Group Policy
setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted
Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0
TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization
may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To
prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you
enable the Use a hardware security device Group Policy object.
Use biometrics
Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather
than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without
sacrificing security.
The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization
may want more time before using biometrics and want to disable their use until they are ready. To not allow
users to use biometrics, configure the Use biometrics Group Policy setting to disabled and apply it to your
computers. The policy setting disabled all biometrics. Currently, Windows does not provide granular policy
setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow
fingerprint.
PIN Complexity
PIN complexity is not specific to Windows Hello for Business. Windows 10 enables users to use PINs outside of
Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when
Windows Hello for Business is not deployed.
Windows 10 provides eight PIN Complexity Group Policy settings that give you granular control over PIN
creation and management. You can deploy these policy settings to computers, where they affect all users
creating PINs on that computer; or, you can deploy these settings to users, where they affect those users
creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group
Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict
resolution is based on the last applied policy. Windows does not merge the policy settings automatically;
however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings
included are:
Require digits
Require lowercase letters
Maximum PIN length
Minimum PIN length
Expiration
History
Require special characters
Require uppercase letters
In the Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove
misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new
location of these Group Policy settings is under Computer Configuration\Administrative Templates\System\PIN
Complexity in the Group Policy editor.
Review
Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10
Creators Editions)
Confirm you configured the Enable Windows Hello for Business to the scope that matches your
deployment (Computer vs. User)
Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
Confirm you configure automatic certificate enrollment to the scope that matches your deployment
(Computer vs. User)
Confirm you configured the proper security settings for the Group Policy object
Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always
have the read permissions)
Add the Windows Hello for Business Users group to the Group Policy object and gave the group the
allow permission for Apply Group Policy
Linked the Group Policy object to the correct locations within Active Directory
Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one
that enables it for users
Add users to the Windows Hello for Business Users group

Users must receive the Windows Hello for Business group policy settings and have the proper permission to
enroll for the WHFB Authentication certificate. You can provide users with these settings and permissions by
adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups that
are not members of this group will not attempt to enroll for Windows Hello for Business.

deployment guide
5. Configure Windows Hello for Business Policy settings (You are here)
Manage Windows Hello for Business in your
organization
Applies to
Windows 10
You can create a Group Policy or mobile device management (MDM) policy that will implement Windows Hello
on devices running Windows 10.
IMPORTANT
The Group Policy setting Turn on PIN sign-in does not apply to Windows Hello for Business. It still prevents or enables
the creation of a convenience PIN for Windows 10, version 1507 and 1511.
Beginning in version 1607, Windows Hello as a convenience PIN is disabled by default on all domain-joined computers. To
enable a convenience PIN for Windows 10, version 1607, enable the Group Policy setting Turn on convenience PIN
sign-in .
Use PIN Complexity policy settings to manage PINs for Windows Hello for Business.
Group Policy settings for Windows Hello for Business

The following table lists the Group Policy settings that you can configure for Windows Hello use in your
workplace. These policy settings are available in User configuration and Computer Configuration under
Policies > Administrative Templates > Windows Components > Windows Hello for Business .
NOTE
Starting with Windows 10, version 1709, the location of the PIN complexity section of the Group Policy is: Computer
Configuration > Administrative Templates > System > PIN Complexity .
P O L IC Y SC O P E O P T IO N S
Use Windows Hello for Computer or user Not configured :

Business Device does not
provision Windows
Hello for Business for
any user.
Enabled : Device
provisions Windows
Hello for Business using
keys or certificates for
all users.
Disabled : Device does
not provision Windows
Hello for Business for
any user.
Use a hardware security Computer Not configured :
device Windows Hello for
Business will be
provisioned using TPM
if available, and will be
provisioned using
software if TPM is not
available.
Enabled : Windows
Hello for Business will
only be provisioned
using TPM. This feature
will provision Windows
Hello for Business using
TPM 1.2 unless the
option to exclude them
is explicitly set.
Disabled : Windows
Hello for Business will
be provisioned using
TPM if available, and
will be provisioned
using software if TPM is
not available.
Use certificate for on- Computer or user Not configured :

premises authentication Windows Hello for
Business enrolls a key
that is used for on-
premises
authentication.
Enabled : Windows
Hello for Business
enrolls a sign-in
certificate using ADFS
that is used for on-
premises
authentication.
Disabled : Windows
Hello for Business
enrolls a key that is
used for on-premises
authentication.
Use PIN recovery Computer Added in Windows 10,
version 1703
Not configured :
Windows Hello for
Business does not
create or store a PIN
recovery secret. PIN
reset does not use the
Azure-based PIN
recovery service.
Enabled : Windows
Hello for Business uses
the Azure-based PIN
recovery service for PIN
reset.
Disabled : Windows
Hello for Business does
not create or store a
PIN recovery secret.
PIN reset does not use
the Azure-based PIN
recovery service.
For more information
about using the PIN
recovery service for PIN
reset see Windows
Hello for Business PIN
Reset.
Use biometrics Computer Not configured :

Biometrics can be used
as a gesture in place of
a PIN.
Enabled : Biometrics
can be used as a
gesture in place of a
PIN.
Disabled : Only a PIN
can be used as a
gesture.
PIN Complexity Require digits Computer Not configured : Users

must include a digit in
their PIN.
Enabled : Users must
include a digit in their
PIN.
Disabled : Users cannot
use digits in their PIN.
Require lowercase letters Computer Not configured : Users
cannot use lowercase
letters in their PIN.
include at least one
lowercase letter in their
PIN.
use lowercase letters in
their PIN.
Maximum PIN length Computer Not configured : PIN

length must be less
than or equal to 127.
Enabled : PIN length
must be less than or
equal to the number
you specify.
Disabled : PIN length
must be less than or
equal to 127.
Minimum PIN length Computer Not configured : PIN

length must be greater
than or equal to 4.
Enabled : PIN length
must be greater than or
equal to the number
you specify.
Disabled : PIN length
must be greater than or
equal to 4.
Expiration Computer Not configured : PIN

does not expire.
Enabled : PIN can be
set to expire after any
number of days
between 1 and 730, or
PIN can be set to never
expire by setting policy
to 0.
Disabled : PIN does not
expire.
History Computer Not configured :
Previous PINs are not
stored.
Enabled : Specify the
number of previous
PINs that can be
associated to a user
account that can't be
reused.
Disabled : Previous
PINs are not stored.
Note Current PIN is

included in PIN history.
Require special characters Computer Not configured : Users

cannot include a special
character in their PIN.
special character in their
PIN.
include a special
character in their PIN.
Require uppercase letters Computer Not configured : Users

cannot include an
uppercase letter in their
PIN.
uppercase letter in their
PIN.
include an uppercase
letter in their PIN.
Phone Sign-in Use Phone Sign-in Computer Not currently

supported.
MDM policy settings for Windows Hello for Business

The following table lists the MDM policy settings that you can configure for Windows Hello for Business use in
your workplace. These MDM policy settings use the PassportForWork configuration service provider (CSP).
IMPORTANT
Starting in Windows 10, version 1607, all devices only have one PIN associated with Windows Hello for Business. This
means that any PIN on a device will be subject to the policies specified in the PassportForWork CSP. The values specified
take precedence over any complexity rules set via Exchange ActiveSync (EAS) or the DeviceLock CSP.
P O L IC Y SC O P E DEFA ULT O P T IO N S
UsePassportForWork Device or user True True: Windows

Hello for
Business will be
provisioned for
all users on the
device.
False: Users will
not be able to
provision
Windows Hello
for Business.
Note If Windows
Hello for Business
is enabled, and
then the policy is
changed to False,
users who
previously set up
Windows Hello
for Business can
continue to use it,
but will not be
able to set up
Windows Hello
for Business on
other devices.
RequireSecurityDevic Device or user False True: Windows

e Hello for
Business will only
be provisioned
using TPM.
False: Windows
Hello for
Business will be
provisioned
using TPM if
available, and will
be provisioned
using software if
TPM is not
available.
ExcludeSecurityDevic TPM12 Device False Added in
e Windows 10,
version 1703
True: TPM
revision 1.2
modules will be
disallowed from
being used with
Windows Hello
for Business.
False: TPM
revision 1.2
modules will be
allowed to be
used with
Windows Hello
for Business.
EnablePinRecovery Device or user False Added in

Windows 10,
version 1703
True: Windows
Hello for
Business uses the
Azure-based PIN
recovery service
for PIN reset.
False: Windows
Hello for
Business does
not create or
store a PIN
recovery secret.
PIN reset does
not use the
Azure-based PIN
recovery service.
For more
information
about using the
PIN recovery
service for PIN
reset see
Windows Hello
for Business PIN
Reset.
Biometrics UseBiometrics Device False True: Biometrics

can be used as a
gesture in place
of a PIN for
domain sign-in.
False: Only a PIN
can be used as a
gesture for
domain sign-in.
FacialFeaturesUse Device Not configured Not configured:
r users can choose
whether to turn
EnhancedAntiSpo on enhanced
ofing anti-spoofing.
True: Enhanced
anti-spoofing is
required on
devices which
support it.
False: Users
cannot turn on
enhanced anti-
spoofing.
PINComplexity Digits Device or user 1 0: Digits are

allowed.
1: At least one
digit is required.
2: Digits are not
allowed.
Lowercase letters Device or user 2 0: Lowercase

letters are
allowed.
1: At least one
lowercase letter
is required.
2: Lowercase
letters are not
allowed.
Special characters Device or user 2 0: Special

characters are
allowed.
1: At least one
special character
is required.
2: Special
characters are
not allowed.
Uppercase letters Device or user 2 0: Uppercase

letters are
allowed.
1: At least one
uppercase letter
is required.
2: Uppercase
letters are not
allowed.
Maximum PIN length Device or user 127 Maximum length
that can be set is
127. Maximum
length cannot be
less than
minimum setting.
Minimum PIN length Device or user 4 Minimum length

that can be set is
4. Minimum
length cannot be
greater than
maximum
setting.
Expiration Device or user 0 Integer value

specifies the
period of time (in
days) that a PIN
can be used
before the
system requires
the user to
change it. The
largest number
you can
configure for this
policy setting is
730. The lowest
number you can
configure for this
policy setting is
0. If this policy is
set to 0, then the
user's PIN will
never expire.
History Device or user 0 Integer value

that specifies the
number of past
PINs that can be
associated to a
user account that
can't be reused.
The largest
number you can
configure for this
policy setting is
50. The lowest
number you can
configure for this
policy setting is
0. If this policy is
set to 0, then
storage of
previous PINs is
not required.
Remote UseRemotePassp Device or user False Not currently
ort supported.
NOTE
In Windows 10, version 1709 and later, if policy is not configured to explicitly require letters or special characters, users
can optionally set an alphanumeric PIN. Prior to version 1709 the user is required to set a numeric PIN.
Policy conflicts from multiple policy sources

Windows Hello for Business is designed to be managed by Group Policy or MDM but not a combination of both.
If policies are set from both sources it can result in a mixed result of what is actually enforced for a user or
device.
Policies for Windows Hello for Business are enforced using the following hierarchy: User Group Policy >
Computer Group Policy > User MDM > Device MDM > Device Lock policy.
Feature enablement policy and certificate trust policy are grouped together and enforced from the same source
(either GP or MDM), based on the rule above. The Use Passport for Work policy is used to determine the
winning policy source.
All PIN complexity policies, are grouped separately from feature enablement and are enforced from a single
policy source. Use a hardware security device and RequireSecurityDevice enforcement are also grouped
together with PIN complexity policy. Conflict resolution for other Windows Hello for Business policies are
enforced on a per policy basis.
NOTE
Windows Hello for Business policy conflict resolution logic does not respect the ControlPolicyConflict/MDMWinsOverGP
policy in the Policy CSP.
Examples
The following are configured using computer Group Policy:
Use Windows Hello for Business - Enabled
User certificate for on-premises authentication - Enabled
The following are configured using device MDM Policy:
UsePassportForWork - Disabled
UseCertificateForOnPremAuth - Disabled
MinimumPINLength - 8
Digits - 1
LowercaseLetters - 1
SpecialCharacters - 1
Enforced policy set:
Use Windows Hello for Business - Enabled
Use certificate for on-premises authentication - Enabled
MinimumPINLength - 8
Digits - 1
LowercaseLetters - 1
SpecialCharacters - 1
How to use Windows Hello for Business with Azure Active Directory
There are three scenarios for using Windows Hello for Business in Azure AD–only organizations:
Organizations that use the version of Azure AD included with Office 365 . For these organizations,
no additional work is necessary. When Windows 10 was released to general availability, Microsoft changed
the behavior of the Office 365 Azure AD stack. When a user selects the option to join a work or school
network, the device is automatically joined to the Office 365 tenant's directory partition, a certificate is issued
for the device, and it becomes eligible for Office 365 MDM if the tenant has subscribed to that feature. In
addition, the user will be prompted to log on and, if MFA is enabled, to enter an MFA proof that Azure AD
sends to his or her phone.
Organizations that use the free tier of Azure AD . For these organizations, Microsoft has not enabled
automatic domain join to Azure AD. Organizations that have signed up for the free tier have the option to
enable or disable this feature, so automatic domain join won't be enabled unless and until the organization's
administrators decide to enable it. When that feature is enabled, devices that join the Azure AD domain by
using the Connect to work or school dialog box will be automatically registered with Windows Hello for
Business support, but previously joined devices will not be registered.
Organizations that have subscribed to Azure AD Premium have access to the full set of Azure AD
MDM features. These features include controls to manage Windows Hello for Business. You can set policies to
disable or force the use of Windows Hello for Business, require the use of a TPM, and control the length and
strength of PINs set on the device.
If you want to use Windows Hello for Business with certificates, you'll need a device registration system. That
means that you set up Configuration Manager, Microsoft Intune, or a compatible non-Microsoft MDM system
and enable it to enroll devices. This is a prerequisite step to use Windows Hello for Business with certificates, no
matter the IDP, because the enrollment system is responsible for provisioning the devices with the necessary
certificates.
Related topics
Deploying Certificates to Key Trust Users to Enable
RDP
Applies To
Hybrid deployment
Key trust
Windows Hello for Business supports using a certificate as the supplied credential when establishing a remote
desktop connection to a server or other device. For certificate trust deployments, creation of this certificate
occurs at container creation time.
This document discusses an approach for key trust deployments where authentication certificates can be
deployed to an existing key trust user.
Three approaches are documented here:
1. Deploying a certificate to hybrid joined devices using an on-premises Active Directory certificate
enrollment policy.
2. Deploying a certificate to hybrid or Azure AD joined devices using Simple Certificate Enrollment Protocol
(SCEP) and Intune.
3. Working with non-Microsoft enterprise certificate authorities.
Deploying a certificate to a hybrid joined device using an on-premises

Active Directory Certificate enrollment policy
Create a Windows Hello for Business certificate template
1. Sign in to your issuing certificate authority (CA).
2. Open the Cer tificate Authority Console (%windir%\system32\certsrv.msc).
3. In the left pane of the MMC, expand Cer tification Authority (Local) , and then expand your CA within
the Certification Authority list.
4. Right-click Cer tificate Templates and then click Manage to open the Cer tificate Templates console.
5. Right-click the Smar tcard Logon template and click Duplicate Template
6. On the Compatibility tab:

a. Clear the Show resulting changes check box
b. Select Windows Ser ver 2012 or Windows Ser ver 2012 R2 from the Certification Authority list
c. Select Windows Ser ver 2012 or Windows Ser ver 2012 R2 from the Certification Recipient list
7. On the General tab:
a. Specify a Template display name, such as WHfB Cer tificate Authentication
b. Set the validity period to the desired value
c. Take note of the Template name for later, which should be the same as the Template display name
minus spaces (WHfBCer tificateAuthentication in this example).
9. On the Subject Name tab:
a. Select the Build from this Active Director y information button if it is not already selected
b. Select Fully distinguished name from the Subject name format list if Fully distinguished name is
not already selected
c. Select the User Principal Name (UPN) check box under Include this information in alternative
subject name
10. On the Request Handling tab:
a. Select the Renew with same key check box
b. Set the Purpose to Signature and smar tcard logon
a. Click Yes when prompted to change the certificate purpose
c. Click Prompt the user during enrollment
11. On the Cr yptography tab:
a. Set the Provider Category to Key Storage Provider
b. Set the Algorithm name to RSA
c. Set the minimum key size to 2048
d. Select Requests must use one of the following providers
e. Tick Microsoft Software Key Storage Provider
f. Set the Request hash to SHA256
12. On the Security tab, add the security group that you want to give Enroll access to. For example, if you
want to give access to all users, select the Authenticated users group, and then select Enroll permissions
for them .
13. Click OK to finalize your changes and create the new template. Your new template should now appear in
the list of Certificate Templates.
14. Close the Certificate Templates console.
15. Open an elevated command prompt and change to a temporary working directory.
16. Execute the following command:
certutil -dstemplate <TemplateName> > <TemplateName>.txt
Replace <TemplateName> with the Template name you took note of earlier in step 7.
17. Open the text file created by the command above.
a. Delete the last line of the output from the file that reads Cer tUtil: -dsTemplate command
completed successfully.
b. Modify the line that reads pKIDefaultCSPs = "1,Microsoft Software Key Storage Provider" to
pKIDefaultCSPs = "1,Microsoft Passpor t Key Storage Provider"
18. Save the text file.
19. Update the certificate template by executing the following command:
certutil - dsaddtemplate <TemplateName>.txt
20. In the Certificate Authority console, right-click Cer tificate Templates , select New , and select
Cer tificate Template to Issue
21. From the list of templates, select the template you previously created (WHFB Cer tificate
Authentication ) and click OK . It can take some time for the template to replicate to all servers and
become available in this list.
22. After the template replicates, in the MMC, right-click in the Certification Authority list, click All Tasks and
then click Stop Ser vice . Right-click the name of the CA again, click All Tasks , and then click Star t
Ser vice .
Requesting a Certificate
1. Ensure the hybrid Azure AD joined device has network line of sight to Active Directory domain controllers
and the issuing certificate authority.
2. Start the Cer tificates – Current User console (%windir%\system32\certmgr.msc).
3. In the left pane of the MMC, right-click Personal , click All Tasks , and then click Request New
Cer tificate…
4. On the Certificate Enrollment screen, click Next .

5. Under Select Certificate Enrollment Policy, ensure Active Director y Enrollment Policy is selected and
then click Next .
6. Under Request Certificates, click the check-box next to the certificate template you created in the previous
section (WHfB Certificate Authentication) and then click Enroll .
7. After a successful certificate request, click Finish on the Certificate Installation Results screen
Deploying a certificate to Hybrid or Azure AD Joined Devices using

Simple Certificate Enrollment Protocol (SCEP) via Intune
Deploying a certificate to Azure AD Joined Devices may be achieved with the Simple Certificate Enrollment
Protocol (SCEP) via Intune. For guidance deploying the required infrastructure, refer to Configure infrastructure
to support SCEP certificate profiles with Microsoft Intune.
Next you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to
Azure AD Joined Devices using a Trusted root certificate profile with Intune. For guidance, refer to Create trusted
certificate profiles in Microsoft Intune.
Once these requirements have been met, a new device configuration profile may be configured from Intune that
provisions a certificate for the user of the device. Proceed as follows:
1. Sign in to the Microsoft Endpoint Manager admin center.
2. Navigate to Devices > Configuration Profiles > Create profile.
3. Enter the following properties:
a. For Platform, select Windows 10 and later .
b. For Profile, select SCEP Cer tificate .
c. Click Create .
4. In Basics , enter the following parameters:
a. Name : Enter a descriptive name for the profile. Name your profiles so you can easily identify them
later. For example, a good profile name is SCEP profile for entire company.
b. Description : Enter a description for the profile. This setting is optional, but recommended.
c. Select Next .
5. In the Configuration settings , complete the following:
a. For Certificate Type, choose User .
b. For Subject name format, set it to CN={{UserPrincipalName}} .
c. Under Subject alternative name, select User principal name (UPN) from the drop-down menu
and set the value to CN={{UserPrincipalName}} .
d. For Certificate validity period, set a value of your choosing.
e. For Key storage provider (KSP), choose Enroll to Windows Hello for Business, other wise fail
(Windows 10 and later) .
f. For Key usage, choose Digital Signature .
g. For Key size (bits), choose 2048 .
h. For Hash algorithm, choose SHA-2 .
i. Under Root Certificate, click +Root Cer tificate and select the trusted certificate profile you
created earlier for the Root CA Certificate.
j. Under Extended key usage, add the following:
NAME O B JEC T IDEN T IF IER P REDEF IN ED VA L UES
Smart Card Logon 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
Client Authentication 1.3.6.1.5.5.7.3.2 Client Authentication
k. For Renewal threshold (%), set a value of your choosing.

l. For SCEP Server URLs, provide the public endpoint that you configured during the deployment of
your SCEP infrastructure.
m. Click Next
6. In Assignments, target the devices or users who should receive a certificate and click Next
7. In Applicability Rules, provide additional issuance restrictions if required and click Next
8. In Review + create, click Create
Once the configuration profile has been created, targeted clients will receive the profile from Intune on their next
refresh cycle. You should find a new certificate in the user store. To validate the certificate is present, do the
following steps:
1. Open the Certificates - Current User console (%windir%\system32\certmgr.msc)
2. In the left pane of the MMC, expand Personal and select Cer tificates
3. In the right-hand pane of the MMC, check for the new certificate
NOTE
This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid AAD-Joined devices
using Intune Policies.
Using non-Microsoft Enterprise Certificate Authorities

If you are using a Public Key Infrastructure that uses non-Microsoft services, the certificate templates published
to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with
non-Microsoft PKI deployments, refer to Use third-party certification authorities (CA) with SCEP in Microsoft
Intune.
As an alternative to using SCEP or if none of the previously covered solutions will work in your environment,
you can manually generate Certificate Signing Requests (CSR) for submission to your PKI. To assist with this
approach, you can use the Generate-CertificateRequest PowerShell commandlet.
The Generate-CertificateRequest commandlet will generate an .inf file for a pre-existing Windows Hello for
Business key. The .inf can be used to generate a certificate request manually using certreq.exe. The commandlet
will also generate a .req file, which can be submitted to your PKI for a certificate.
RDP Sign-in with Windows Hello for Business Certificate

Authentication
After adding the certificate using an approach from any of the previous sections, you should be able to RDP to
any Windows device or server in the same Forest as the user’s on-premises Active Directory account, provided
the PKI certificate chain for the issuing certificate authority is deployed to that target server.
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid AAD-Joined client where
the authentication certificate has been deployed.
2. Attempt an RDP session to a target server.
3. Use the certificate credential protected by your Windows Hello for Business gesture.
Conditional access
Requirements:
Hybrid Windows Hello for Business deployment
In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, applications, and
services from anywhere. With the proliferation of devices (including BYOD), work off corporate networks, and
3rd party SaaS applications, IT professionals are faced with two opposing goals:
Empower the end users to be productive wherever and whenever
Protect the corporate assets at any time
To improve productivity, Azure Active Directory provides your users with a broad range of options to access
your corporate assets. With application access management, Azure Active Directory enables you to ensure that
only the right people can access your applications. What if you want to have more control over how the right
people are accessing your resources under certain conditions? What if you even have conditions under which
you want to block access to certain applications even for the right people? For example, it might be OK for you if
the right people are accessing certain applications from a trusted network; however, you might not want them
to access these applications from a network you don't trust. You can address these questions using conditional
access.
NOTE
For more details about the way Windows Hello for Business interacts with Azure AD Multi-Factor Authentication and
Conditional Access, see this article.
Read Conditional access in Azure Active Directory to learn more about Conditional Access. Afterwards, read
Getting started with conditional access in Azure Active Directory to start deploying Conditional access.
Related topics
PIN reset
Applies to:
Hybrid Deployments
Requirements:
Hybrid Windows Hello for Business deployment
Azure AD registered, Azure AD joined, and Hybrid Azure AD joined
Windows 10, version 1709 to 1809, Enterprise Edition . There is no licensing requirement for this feature
since version 1903.
The Microsoft PIN reset services enables you to help users recover who have forgotten their PIN. Using Group
Policy, Microsoft Intune or a compatible MDM, you can configure Windows 10 devices to securely use the
Microsoft PIN reset service that enables users to reset their forgotten PIN through settings or above the lock
screen without requiring re-enrollment.
IMPORTANT
The Microsoft PIN Reset service only works with Enterprise Edition for Windows 10, version 1709 to 1809. The feature
works with Enterprise Edition and Pro edition with Windows 10, version 1903 and newer.
Onboarding the Microsoft PIN reset service to your Intune tenant

Before you can remotely reset PINs, you must on-board the Microsoft PIN reset service to your Azure Active
Directory tenant, and configure devices you manage.
Connect Azure Active Directory with the PIN reset service
1. Go to the Microsoft PIN Reset Service Production website, and sign in using the Global administrator
account you use to manage your Azure Active Directory tenant.
2. After you have logged in, choose Accept to give consent for the PIN reset service to access your account.
3. Go to the Microsoft PIN Reset Client Production website, and sign in using the Global administrator
account you use to manage your Azure Active Directory tenant.
4. After you have logged in, choose Accept to give consent for the PIN reset client to access your account.
NOTE
After you have accepted the PIN reset service and client requests, you will land on a page that states "You do not have
permission to view this directory or page." This behavior is expected. Be sure to confirm that the two PIN reset
applications are listed for your tenant. 5. In the Azure portal, verify that the Microsoft PIN Reset Service and Microsoft PIN
Reset Client are integrated from the Enterprise applications blade. Filter to application status "Enabled" and both
Microsoft Pin Reset Service Production and Microsoft Pin Reset Client Production will show up in your tenant.
Configure Windows devices to use PIN reset using Group Policy

You configure Windows 10 to use the Microsoft PIN Reset service using the computer configuration portion of a
Group Policy object.
1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer
accounts in Active Directory.
2. Edit the Group Policy object from Step 1.
3. Enable the Use PIN Recover y policy setting located under Computer Configuration >
Administrative Templates > Windows Components > Windows Hello for Business .
4. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
Create a PIN Reset Device configuration profile using Microsoft Intune
1. Sign-in to Endpoint Manager admin center using a Global administrator account.
2. Click Endpoint Security > Account Protection > Proper ties .
3. Set Enable PIN recover y to Yes .
NOTE
You can also setup PIN recovery using configuration profiles.
1. Sign in to Endpoint Manager.
2. Click Devices > Configuration Profiles > Create a new profile or edit an existing profile using the Identity
Protection profile type.
3. Set Enable PIN recover y to Yes .
Assign the PIN Reset Device configuration profile using Microsoft Intune
1. Sign in to the Azure portal using a Global administrator account.
2. Navigate to the Microsoft Intune blade. Choose Device configuration > Profiles . From the list of
device configuration profiles, choose the profile that contains the PIN reset configuration.
3. In the device configuration profile, select Assignments .
4. Use the Include and/or Exclude tabs to target the device configuration profile to select groups.
On-premises Deployments
Requirements
Active Directory
On-premises Windows Hello for Business deployment
Reset above Lock - Windows 10, version 1709, Professional
On-premises deployments provide users with the ability to reset forgotten PINs either through the settings page
or from above the user's lock screen. Users must know or be provided their password for authentication, must
perform a second factor of authentication, and then re-provision Windows Hello for Business.
IMPORTANT
Users must have corporate network connectivity to domain controllers and the federation service to reset their PINs.
Reset PIN from Settings

1. Sign-in to Windows 10, version 1703 or later using an alternate credential.
2. Open Settings , click Accounts , click Sign-in options .
3. Under PIN , click I forgot my PIN and follow the instructions.
Reset PIN above the Lock Screen
1. On Windows 10, version 1709, click I forgot my PIN from the Windows Sign-in
2. Enter your password and press enter.
3. Follow the instructions provided by the provisioning process
4. When finished, unlock your desktop using your newly created PIN.
You may find that PIN reset from settings only works post login, and that the "lock screen" PIN reset function will
not work if you have any matching limitation of SSPR password reset from the lock screen. For more
information, see Enable Azure Active Directory self-service password reset at the Windows sign-in screen -
General limitations .
NOTE
Visit the Windows Hello for Business Videos page and watch Windows Hello for Business forgotten PIN user experience.
Related topics
Dual Enrollment
Requirements
Hybrid and On-premises Windows Hello for Business deployments
Enterprise Joined or Hybrid Azure joined devices
NOTE
This feature was previously known as Privileged Credential but was renamed to Dual Enrollment to prevent any
confusion with the Privileged Access Workstation feature.
IMPORTANT
Dual enrollment does not replace or provide the same security as Privileged Access Workstations feature. Microsoft
encourages enterprises to use the Privileged Access Workstations for their privileged credential users. Enterprises can
consider Windows Hello for Business dual enrollment in situations where the Privileged Access feature cannot be used.
Read Privileged Access Workstations for more information.
Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their
non-privileged and privileged credentials on their device.
By design, Windows 10 does not enumerate all Windows Hello for Business users from within a user's session.
Using the computer Group Policy setting, Allow enumeration of emulated smar t card for all users , you
can configure a device to enumerate all enrolled Windows Hello for Business credentials on selected devices.
With this setting, administrative users can sign-in to Windows 10, version 1709 using their non-privileged
Windows Hello for Business credentials for normal work flow such as email, but can launch Microsoft
Management Consoles (MMCs), Remote Desktop Services clients, and other applications by selecting Run as
different user or Run as administrator , selecting the privileged user account, and providing their PIN.
Administrators can also take advantage of this feature with command line applications by using runas.exe
combined with the /smar tcard argument. This enables administrators to perform their day-to-day operations
without needing to sign-in and out, or use fast user switching when alternating between privileged and non-
privileged workloads.
IMPORTANT
You must configure a Windows 10 computer for Windows Hello for Business dual enrollment before either user (privileged
or non-privileged) provisions Windows Hello for Business. Dual enrollment is a special setting that is configured on the
Windows Hello container during creation.
Configure Windows Hello for Business Dual Enrollment

In this task you will
Configure Active Directory to support Domain Administrator enrollment
Configure Dual Enrollment using Group Policy
Configure Active Directory to support Domain Administrator enrollment
The designed Windows Hello for Business configuration gives the Key Admins (or KeyCredential Admins
when using domain controllers prior to Windows Server 2016) group read and write permissions to the msDS-
KeyCredentialsLink attribute. You provided these permissions at root of the domain and use object inheritance
to ensure the permissions apply to all users in the domain regardless of their location within the domain
hierarchy.
Active Directory Domain Services uses AdminSDHolder to secure privileged users and groups from
unintentional modification by comparing and replacing the security on privileged users and groups to match
those defined on the AdminSDHolder object on an hourly cycle. For Windows Hello for Business, your domain
administrator account may receive the permissions but they will disappear from the user object unless you give
the AdminSDHolder read and write permissions to the msDS-KeyCredential attribute.
1. Type the following command to add the allow read and write property permissions for msDS-
KeyCredentialLink attribute for the Key Admins (or KeyCredential Admins ) group on the AdminSDHolder
object.
dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /g "[domainName\keyAdminGroup]":RPWP;msDS-
KeyCredentialLink
where DC=domain,DC=com is the LDAP path of your Active Directory domain and
domainName\keyAdminGroup] is the NetBIOS name of your domain and the name of the group you use
to give access to keys based on your deployment. For example:
dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net" /g "mstepdemo\Key Admins":RPWP;msDS-
KeyCredentialLink
2. To trigger security descriptor propagation, open ldp.exe .
3. Click Connection and select Connect... Next to Ser ver , type the name of the domain controller that holds
the PDC role for the domain. Next to Por t , type 389 and click OK .
4. Click Connection and select Bind... Click OK to bind as the currently signed-in user.
5. Click Browser and select Modify . Leave the DN text box blank. Next to Attribute , type
RunProtectAdminGroupsTask . Next to Values , type 1 . Click Enter to add this to the Entr y List .
6. Click Run to start the task.
7. Close LDP.
Configuring Dual Enrollment using Group Policy
You configure Windows 10 to support dual enrollment using the computer configuration portion of a Group
Policy object.
1. Using the Group Policy Management Console (GPMC), create a new domain-based Group Policy object and
link it to an organizational Unit that contains Active Directory computer objects used by privileged users.
2. Edit the Group Policy object from step 1.
3. Enable the Allow enumeration of emulated smar t cards for all users policy setting located under
Computer Configuration->Administrative Templates->Windows Components->Windows Hello
for Business .
4. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
5. Restart computers targeted by this Group Policy object.
The computer is ready for dual enrollment. Sign-in as the privileged user first and enroll for Windows Hello for
Business. Once completed, sign-out and sign-in as the non-privileged user and enroll for Windows Hello for
Business. You can now use your privileged credential to perform privileged tasks without using your password
and without needing to switch users.
Related topics
Dynamic lock
Requirements:
Dynamic lock enables you to configure Windows 10 devices to automatically lock when Bluetooth paired device
signal falls below the maximum Received Signal Strength Indicator (RSSI) value. This makes it more difficult for
someone to gain access to your device if you step away from your PC and forget to lock it.
You configure the dynamic lock policy using Group Policy. You can locate the policy setting at Computer
Configuration\Administrative Templates\Windows Components\Windows Hello for Business . The
name of the policy is Configure dynamic lock factors .
The Group Policy Editor, when the policy is enabled, creates a default signal rule policy with the following value:
<rule schemaVersion="1.0">
<signal type="bluetooth" scenario="Dynamic Lock" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</rule>
IMPORTANT
Microsoft recommends using the default values for this policy settings. Measurements are relative based on the varying
conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each
environment prior to broadly deploying the setting.
For this policy setting, the type and scenario attribute values are static and cannot change. The classofDevice
is configurable but Phone is the only currently supported configuration. The attribute defaults to Phones sand
uses the values from the following table:
DESC RIP T IO N VA L UE
Miscellaneous 0
Computer 256
Phone 512
LAN/Network Access Point 768
Audio/Video 1024
Peripheral 1280
Imaging 1536
Wearable 1792
Toy 2048
Health 2304
Uncategorized 7936
The rssiMin attribute value signal indicates the strength needed for the device to be considered "in-range". The
default value of -10 enables a user to move about an average size office or cubicle without triggering Windows
to lock the device. The rssiMaxDelta has a default value of -10 , which instruct Windows 10 to lock the device
once the signal strength weakens by more than measurement of 10.
RSSI measurements are relative and lower as the bluetooth signals between the two paired devices reduces.
Therefore a measurement of 0 is stronger than -10, which is stronger than -60, which is an indicator the devices
are moving further apart from each other.
Related topics
Multi-factor Unlock
Applies to:
Windows 10
Requirements:
Windows Hello for Business deployment (Hybrid or On-premises)
Azure AD, Hybrid Azure AD, or Domain Joined (Cloud, Hybrid, or On-Premises deployments)
Windows 10, version 1709 or newer
Bluetooth, Bluetooth capable phone - optional
Windows, today, natively only supports the use of a single credential (password, PIN, fingerprint, face, etc.) for
unlocking a device. Therefore, if any of those credentials are compromised (shoulder surfed), an attacker could
gain access to the system.
Windows 10 offers Multi-factor device unlock by extending Windows Hello with trusted signals. Administrators
can configure Windows 10 to request a combination of factors and trusted signals to unlock their devices.
Which organizations can take advantage of Multi-factor unlock? Those who:
Have expressed that PINs alone do not meet their security needs.
Want to prevent Information Workers from sharing credentials.
Want their organizations to comply with regulatory two-factor authentication policy.
Want to retain the familiar Windows sign-in user experience and not settle for a custom solution.
You enable multi-factor unlock using Group Policy. The Configure device unlock factors policy setting is
located under Computer Configuration\Administrative Templates\Windows Components\Windows
Hello for Business .
The Basics: How it works

First unlock factor credential provider and Second unlock credential provider are responsible for the bulk of the
configuration. Each of these components contains a globally unique identifier (GUID) that represents a different
Windows credential provider. With the policy setting enabled, users unlock the device using at least one
credential provider from each category before Windows allows the user to proceed to their desktop.
The policy setting has three components:
First unlock factor credential provider
Second unlock factor credential provider
Signal rules for device unlock
Configuring Unlock Factors

The First unlock factor credential providers and Second unlock factor credential providers portion of
the policy setting each contain a comma separated list of credential providers.
Supported credential providers include:
C REDEN T IA L P RO VIDER GUID
PIN {D6886603-9D2F-4EB2-B667-1971041FA96B}
Fingerprint {BEC09223-B018-416D-A0AC-523971B639F5}
Facial Recognition {8AF662BF-65A0-4D0A-A540-A338A999D36F}
Trusted Signal {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}

(Phone proximity, Network location)
NOTE
Multifactor unlock does not support third-party credential providers or credential providers not listed in the above table.
The default credential providers for the First unlock factor credential provider include:
PIN
Fingerprint
Facial Recognition
The default credential providers for the Second unlock factor credential provider include:
Trusted Signal
PIN
Configure a comma separated list of credential provider GUIDs you want to use as first and second unlock
factors. While a credential provider can appear in both lists, remember that a credential supported by that
provider can only satisfy one of the unlock factors. Listed credential providers do not need to be in any specific
order.
For example, if you include the PIN and fingerprint credential providers in both first and second factor lists, a
user can use their fingerprint or PIN as the first unlock factor. However, whichever factor they used to satisfy the
first unlock factor cannot be used to satisfy the second unlock factor. Each factor can therefore be used exactly
once. The Trusted Signal provider can only be specified as part of the Second unlock factor credential provider
list.
Configure Signal Rules for the Trusted Signal Credential Provider

The Signal rules for device unlock setting contains the rules the Trusted Signal credential provider uses to
satisfy unlocking the device.
Rule element
You represent signal rules in XML. Each signal rule has an starting and ending rule element that contains the
schemaVersion attribute and value. The current supported schema version is 1.0.
Example
</rule>
Signal element
Each rule element has a signal element. All signal elements have a type element and value. Windows 10,
version 1709 supports the ipConfig and bluetooth type values.
AT T RIB UT E VA L UE
type "bluetooth" or "ipConfig" (Windows 10, version 1709)
type "wifi" (Windows 10, version 1803)
Bluetooth
You define the bluetooth signal with additional attributes in the signal element. The bluetooth configuration
does not use any other elements. You can end the signal element with short ending tag "/>".
AT T RIB UT E VA L UE REQ UIRED
type "bluetooth" yes
scenario "Authentication" yes
classOfDevice "number" no
rssiMin "number" no
rssiMaxDelta "number" no
Example
<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-
10"/>
</rule>
The classofDevice attribute defaults to Phone and uses the values from the following table:
Miscellaneous 0
Computer 256
Phone 512
LAN/Network Access Point 768
Audio/Video 1024
Peripheral 1280
Imaging 1536
Wearable 1792
Toy 2048
Health 2304
Uncategorized 7936
The rssiMin attribute value signal indicates the strength needed for the device to be considered "in-range". The
default value of -10 enables a user to move about an average size office or cubicle without triggering Windows
to lock the device. The rssiMaxDelta has a default value of -10 , which instruct Windows 10 to lock the device
once the signal strength weakens by more than measurement of 10.
RSSI measurements are relative and lower as the bluetooth signals between the two paired devices reduces.
Therefore a measurement of 0 is stronger than -10, which is stronger than -60, which is an indicator the devices
are moving further apart from each other.
IMPORTANT
Microsoft recommends using the default values for this policy setting. Measurements are relative, based on the varying
conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each
environment prior to broadly deploying the setting. Use the rssiMIN and rssiMaxDelta values from the XML file created
by the Group Policy Management Editor or remove both attributes to use the default values.
IP Configuration
You define IP configuration signals using one or more ipConfiguration elements. Each element has a string
value. IpConfiguration elements do not have attributes or nested elements.
I P v 4 P r e fi x
The IPv4 network prefix represented in Internet standard dotted-decimal notation. A network prefix that uses the
Classless Inter-Domain Routing (CIDR) notation is required as part of the network string. A network port must
not be present in the network string. A signal element may only contain one ipv4Prefix element.
Example
<ipv4Prefix>192.168.100.0/24</ipv4Prefix>
The assigned IPv4 addresses in the range of 192.168.100.1 to 192.168.100.254 match this signal configuration.
IPv4 Gat ew ay
The IPv4 network gateway represented in Internet standard dotted-decimal notation. A network port or prefix
must not be present in the network string. A signal element may only contain one ipv4Gateway element.
Example
<ipv4Gateway>192.168.100.10</ipv4Gateway>
I P v 4 D h c p Se r v e r
The IPv4 DHCP server represented in Internet standard dotted-decimal notation. A network port or prefix must
not be present in the network string. A signal element may only contain one ipv4DhcpSer ver element.
Example
<ipv4DhcpServer>192.168.100.10</ipv4DhcpServer>
I P v 4 D n s Se r v e r
The IPv4 DNS server represented in Internet standard dotted-decimal notation. A network port or prefix must
not be present in the network string.The signal element may contain one or more ipv4DnsSer ver elements.
Example:
<ipv4DnsServer>192.168.100.10</ipv4DnsServer>
I P v 6 P r e fi x
The IPv6 network prefix represented in IPv6 network using Internet standard hexadecimal encoding. A network
prefix in CIDR notation is required as part of the network string. A network port or scope ID must not be present
in the network string. A signal element may only contain one ipv6Prefix element.
Example
<ipv6Prefix>21DA:D3::/48</ipv6Prefix>
IPv6 Gat ew ay
The IPv6 network gateway represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be
present in the network string. A network port or prefix must not be present in the network string. A signal
element may only contain one ipv6Gateway element.
Example
<ipv6Gateway>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6Gateway>
I P v 6 D h c p Se r v e r
The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present
in the network string. A network port or prefix must not be present in the network string. A signal element may
only contain one ipv6DhcpSer ver element.
Example
<ipv6DhcpServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DhcpServer
I P v 6 D n s Se r v e r
The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present
in the network string. A network port or prefix must not be present in the network string. The signal element
may contain one or more ipv6DnsSer ver elements.
Example
<ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>
d n s Su ffi x
The fully qualified domain name of your organization's internal DNS suffix where any part of the fully qualified
domain name in this setting exists in the computer's primary DNS suffix. The signal element may contain one
or more dnsSuffix elements.
Example
<dnsSuffix>corp.contoso.com</dnsSuffix>
Wi-Fi
Applies to:
You define Wi-Fi signals using one or more wifi elements. Each element has a string value. Wifi elements do not
have attributes or nested elements.
SSID
Contains the service set identifier (SSID) of a wireless network. The SSID is the name of the wireless network.
The SSID element is required.
<ssid>corpnetwifi</ssid>
BSSID
Contains the basic service set identifier (BSSID) of a wireless access point. the BSSID is the mac address of the
wireless access point. The BSSID element is optional.
Example
<bssid>12-ab-34-ff-e5-46</bssid>
Security
Contains the type of security the client uses when connecting to the wireless network. The security element is
required and must contain one of the following values:
VA L UE DESC RIP T IO N
Open The wireless network is an open network that does not

require any authentication or encryption.
WEP The wireless network is protected using Wired Equivalent

Privacy.
WPA-Personal The wireless network is protected using Wi-Fi Protected

Access.
WPA-Enterprise The wireless network is protected using Wi-Fi Protected

Access-Enterprise.
WPA2-Personal The wireless network is protected using Wi-Fi Protected

Access 2, which typically uses a pre-shared key.
WPA2-Enterprise The wireless network is protected using Wi-Fi Protected

Access 2-Enterprise.
Example
<security>WPA2-Enterprise</security>
TrustedRootCA
Contains the thumbprint of the trusted root certificate of the wireless network. This may be any valid trusted
root certificate. The value is represented as hexadecimal string where each byte in the string is separated by a
single space. This element is optional.
Example
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
Sig_quality
Contains numeric value ranging from 0 to 100 to represent the wireless network's signal strength needed to be
considered a trusted signal.
Example
<sig_quality>80</sig_quality>
Sample Trusted Signal Configurations

These examples are wrapped for readability. Once properly formatted, the entire XML contents must be a single
line.
Example 1
This example configures an IPConfig signal type using Ipv4Prefix, Ipv4DnsServer, and DnsSuffix elements.
<signal type="ipConfig">
<ipv4Prefix>10.10.10.0/24</ipv4Prefix>
</signal>
</rule>
Example 2
This example configures an IpConfig signal type using a dnsSuffix element and a bluetooth signal for phones.
This configuration is wrapped for reading. Once properly formatted, the entire XML contents must be a single
line. This example implies that either the ipconfig or the Bluetooth rule must evaluate to true, for the resulting
signal evaluation to be true.
NOTE
Separate each rule element using a comma.
</signal>
</rule>,
<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</rule>
Example 3
This example configures the same as example 2 using compounding And elements. This example implies that
the ipconfig and the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.
<and>
<dnsSuffix>corp.microsoft.com</dnsSuffix>
</signal>
<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</and>
</rule>
Example 4
This example configures Wi-Fi as a trusted signal (Windows 10, version 1803)
<signal type="wifi">
<ssid>contoso</ssid>
<bssid>12-ab-34-ff-e5-46</bssid>
<security>WPA2-Enterprise</security>
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
<sig_quality>80</sig_quality>
</signal>
</rule>
Deploying Multifactor Unlock

IMPORTANT
You need to remove all third party credential providers to ensure users cannot unlock their devices if they do not have
the required factors. The fall back options are to use passwords or smart cards (both of which could be disabled as
needed).
How to configure Multifactor Unlock policy settings

provides the latest Windows Hello for Business Group Policy settings, which includes multi-factor unlock. To run
the Group Policy Management Console, you need to install the Remote Server Administration Tools for
Windows 10. You can download these tools from the Microsoft Download Center. Install the Remote Server
Administration Tools for Windows 10 on a computer running Windows 10, version 1709.
Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10, version 1703 to their
respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them
their respective language folder. See How to create and manage the Central Store for Group Policy
Administrative Templates in Windows for more information.
Create the Multifactor Unlock Group Policy object
IMPORTANT
PIN must be in at least one of the groups
Trusted signals must be combined with another credential provider
You cannot use the same unlock factor to satisfy both categories. Therefore, if you include any credential provider in
both categories, it means it can satisfy either category, but not both.
The multifactor unlock feature is also supported via the Passport for Work CSP. See Passport For Work CSP for more
information.

4. Type Multifactor Unlock in the name box and click OK .
5. In the content pane, right-click the Multifactor Unlock Group Policy object and click Edit .
7. Expand Administrative Templates > Windows Component , and select Windows Hello for
Business .
8. In the content pane, double-click Configure device unlock factors . Click Enable . The Options section
populates the policy setting with default values.
9. Configure first and second unlock factors using the information in Configure Unlock Factors.
10. If using trusted signals, configure the trusted signals used by the unlock factor using the information in
Configure Signal Rules for the Trusted Signal Credential Provider.
11. Click OK to close the Group Policy Management Editor . Use the Group Policy Management
Console to deploy the newly created Group Policy object to your organization's computers.
Troubleshooting
Multi-factor unlock writes events to event log under Application and Ser vices
Logs\Microsoft\Windows\HelloForBusiness with the category name Device Unlock .
Events
EVEN T ID DETA IL S
3520 Unlock attempt initiated
5520 Unlock policy not configured
6520 Warning event
7520 Error event
8520 Success event

Remote Desktop
Requirements
Windows 10
Cloud only, Hybrid, and On-premises only Windows Hello for Business deployments
Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices
Windows Hello for Business supports using a certificate deployed to a Windows Hello for Business container as
a supplied credential to establish a remote desktop connection to a server or another device. This functionality is
not supported for key trust deployments. This feature takes advantage of the redirected smart card capabilities
of the remote desktop protocol. Windows Hello for Business key trust can be used with Windows Defender
Remote Credential Guard.
Microsoft continues to investigate supporting using keys trust for supplied credentials in a future release.
Remote Desktop with Biometrics

Requirements
Cloud only, Hybrid, and On-premises only Windows Hello for Business deployments
Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices
Biometric enrollments
Users using earlier versions of Windows 10 could remote desktop to using Windows Hello for Business but
were limited to the using their PIN as their authentication gesture. Windows 10, version 1809 introduces the
ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric
gesture. The feature is on by default, so your users can take advantage of it as soon as they upgrade to Windows
10, version 1809.
How does it work
Windows generates and stores cryptographic keys using a software component called a key storage provider
(KSP). Software-based keys are created and stored using the Microsoft Software Key Storage Provider. Smart
card keys are created and stored using the Microsoft Smart Card Key Storage Provider. Keys created and
protected by Windows Hello for Business are created and stored using the Microsoft Passport Key Storage
Provider.
A certificate on a smart card starts with creating an asymmetric key pair using the Microsoft Smart Card KSP.
Windows requests a certificate based on the key pair from your enterprises issuing certificate authority, which
returns a certificate that is stored in the user's Personal certificate store. The private key remains on the smart
card and the public key is stored with the certificate. Metadata on the certificate (and the key) store the key
storage provider used to create the key (remember the certificate contains the public key).
This same concept applies to Windows Hello for Business. Except, the keys are created using the Microsoft
Passport KSP and the user's private key remains protected by the device's security module (TPM) and the user's
gesture (PIN/biometric). The certificate APIs hide this complexity. When an application uses a certificate, the
certificate APIs locate the keys using the saved key storage provider. The key storage providers directs the
certificate APIs on which provider they use to find the private key associated with the certificate. This is how
Windows knows you have a smart card certificate without the smart card inserted (and prompts you to insert
the smart card).
Windows Hello for Business emulates a smart card for application compatibility. Versions of Windows 10 prior
to version 1809, would redirect private key access for Windows Hello for Business certificate to use its emulated
smart card using the Microsoft Smart Card KSP, which would enable the user to provide their PIN. Windows 10,
version 1809 no longer redirects private key access for Windows Hello for Business certificates to the Microsoft
Smart Card KSP-- it continues using the Microsoft Passport KSP. The Microsoft Passport KSP enabled Windows
10 to prompt the user for their biometric gesture or PIN.
Compatibility
Users appreciate convenience of biometrics and administrators value the security however, you may experience
compatibility issues with your applications and Windows Hello for Business certificates. You can relax knowing a
Group Policy setting and a MDM URI exist to help you revert to the previous behavior for those users who need
it.
IMPORTANT
The remote desktop with biometric feature does not work with Dual Enrollment feature or scenarios where the user
provides alternative credentials. Microsoft continues to investigate supporting the feature.
Related topics
Windows Hello for Business Known Deployment
Issues
The content of this article is to help troubleshoot and workaround known deployment issues for Windows Hello
for Business. Each issue below will describe the applicable deployment type Windows versions.
Hybrid Key Trust Logon Broken Due to User Public Key Deletion
Applies to:
Hybrid key trust deployments
Windows Server 2016, builds 14393.3930 to 14393.4048
Windows Server 2019, builds 17763.1457 to 17763.1613
In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and
Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-
ins will fail until the user's key is synced during the next Azure AD Connect delta sync cycle.
Identifying User Public Key Deletion Issue
After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key
must sync from Azure AD to AD during an Azure AD Connect sync cycle. The user's public key will be written to
the msDS-KeyCredentialLink attribute of the user object.
Before the user's Windows Hello for Business key is synced, sign-in's with Windows Hello for Business will fail
with the error message, "That option is temporarily unavailable. For now, please use a different method to sign
in." After the sync is successful, the user should be able to login and unlock with their PIN or enrolled biometrics.
In environments impacted with this issue, after the first sign-in with Windows Hello for Business after
provisioning is completed, the next sign-in attempt will fail. In environments where domain controllers are
running a mix of builds, only some may be impacted by this issue and subsequent logon attempts may be sent
different domain controllers. This may result in the sign-in failures appearing to be intermittent.
After the initial logon attempt, the user's Windows Hello for Business public key is being deleted from the
msDS-KeyCredentialLink attribute. This can be verified by querying a user's msDS-KeyCredentialLink attribute
before and after sign-in. The msDS-KeyCredentialLink can be queried in AD using Get-ADUser and specifying
msds-keycredentiallink for the -Properties parameter.
Resolving User Public Key Deletion Issue
To resolve this behavior, upgrade Windows Server 2016 and 2019 domain controllers to with the latest patches.
For Windows Server 2016, this behavior is fixed in build 14393.4104 (KB4593226) and later. For Windows
Server 2019, this behavior is fixed in build 17763.1637 (KB4592440).
Azure AD Joined Device Access to On-Premises Resources Using Key

Trust and Third-Party Certificate Authority (CA)
Applies to:
Azure AD joined key trust deployments
Third-party certificate authority (CA) issuing domain controller certificates
Windows Hello for Business uses smart card based authentication for many operations. Smart card has special
guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers.
Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises
resources from an Azure AD Joined device does require special configuration when using a third-party CA to
issue domain controller certificates.
For more information, read Guidelines for enabling smart card logon with third-party certification authorities.
Identifying On-premises Resource Access Issues with Third-Party CAs
This issue can be identified using network traces or Kerberos logging from the client. In the network trace, the
client will fail to place a TGS_REQ request when a user attempts to access a resource. On the client, this can be
observed in the Kerberos operation event log under Application and
Ser vices/Microsoft/Windows/Security-Kerberos/Operational . These logs are default disabled. The failure
event for this case will include the following information:
Log Name: Microsoft-Windows-Kerberos/Operational

Source: Microsoft-Windows-Security-Kerberos
Event ID: 107
GUID: {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Description:
The Kerberos client received a KDC certificate that does not have a matched domain name.
Expected Domain Name: ad.contoso.com

Error Code: 0xC000006D
Resolving On-premises Resource Access Issue with Third-Party CAs

To resolve this issue, domain controller certificates need to be updated so the certificate subject contains
directory path of the server object (distinguished name). Example Subject: CN=DC1 OU=Domain Controller,
DC=ad, DC=contoso, DC=com
Alternatively, you can set the subject alternative name (SAN) of the domain controller certificate to contain the
server object's fully qualified domain name and the NETBIOS name of the domain. Example Subject Alternative
Name: dns=dc1.ad.contoso.com dns=ad.contoso.com dns=ad
Key Trust Authentication Broken for Windows Server 2019

Applies to:
Windows Server 2019
Hybrid key trust deployments
On-premises key trust deployments
Domain controllers running early versions of Windows Server 2019 have an issue that prevents key trust
authentication from working properly. Networks traces report KDC_ERR_CLIENT_NAME_MISMATCH.
Identifying Server 2019 Key Trust Authentication Issue
On the client, authentication with Windows Hello for Business will fail with the error message, "That option is
temporarily unavailable. For now, please use a different method to sign in."
This error is usually presented on hybrid Azure AD joined devices in key trust deployments after Windows Hello
for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has
been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been
populated for NGC, then it is possible that this error case is occurring.
The other indicator of this failure case can be identified using network traces. If network traces are captured for a
key trust sign-in event, the traces will show kerberos failing with the error KDC_ERR_CLIENT_NAME_MISMATCH.
Resolving Server 2019 Key Trust Authentication Issue
This issue was fixed in Windows Server 2019, build 17763.316 (KB4487044). Upgrade all Windows Server 2019
domain controllers to Windows Server 2019, build 17763.316 or newer to resolve this behavior.
Certificate Trust Provisioning with AD FS Broken on Windows Server

2019
Applies to:
Windows Server 2019
Hybrid certificate trust deployments
On-premises certificate trust deployments
AD FS running on Windows Server 2019 fails to complete device authentication properly due to an invalid
check of incoming scopes in the request. Device authentication to AD FS is a requirement for Windows Hello for
Business to enroll a certificate using AD FS. The client will block Windows Hello for Business provisioning until
this authentication is successful.
Identifying Certificate Trust with AD FS 2019 Enrollment Issue
The provisioning experience for Windows Hello for Business will launch if a set of prerequisite checks done by
the client are successful. The result of the provisioningAdmin checks is available in event logs under Microsoft-
Windows-User Device Registration. If provisioning is blocked because device authentication has not successfully
occurred, there will be an event ID 362 in the logs that states that User has successfully authenticated to the
enterprise STS: No.
Log Name: Microsoft-Windows-User Device Registration/Admin

Source: Microsoft-Windows-User Device Registration
Date: <Date and time>
Event ID: 362
Task Category: None
Level: Warning
Keywords:
User: <User SID>
Computer: <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.
If a device has recently been joined to a domain, then there may be a delay before the device authentication
occurs. If the failing state of this prerequisite check persists, then it can indicate an issue with the AD FS
configuration.
If this AD FS scope issue is present, event logs on the AD FS server will indicate an authentication failure from
the client. This error will be logged in event logs under AD FS/Admin as event ID 1021 and the event will specify
that the client is forbidden access to resource
'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs':
Log Name: AD FS/Admin

Source: AD FS
Date: <Date and time>
Event ID: 1021
Task Category: None
Level: Error
Keywords: AD FS
User: <ADFS service Account>
Computer: <Date and time>
Description:
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received
invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource
'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String
scopeParameter, String clientId, String relyingPartyId)
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
Resolving Certificate Trust with AD FS 2019 Enrollment Issue

This issue is fixed in Windows Server, version 1903 and later. For Windows Server 2019, this issue can be
remediated by adding the ugs scope manually.
1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
2. Right click "Scope Descriptions" and select "Add Scope Description".
3. Under name type "ugs" and Click Apply > OK.
4. Launch PowerShell as an administrator.
5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to
"38aa3b87-a06d-4817-b275-7a316988d93b":
(Get-AdfsApplicationPermission -ServerRoleIdentifiers
'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq
'38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
6. Execute the command

Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' .
7. Restart the AD FS service.
8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
Applies to
Windows 10
When you set up Windows Hello in Windows 10, you may get an error during the Create a PIN step. This topic
lists some of the error codes with recommendations for mitigating the problem. If you get an error code that is
not listed here, contact Microsoft Support.
Where is the error code?

The following image shows an example of an error during Create a PIN .
Error mitigations
When a user encounters an error when creating the work PIN, advise the user to try the following steps. Many
errors can be mitigated by one of these steps.
1. Try to create the PIN again. Some errors are transient and resolve themselves.
2. Sign out, sign in, and try to create the PIN again.
3. Reboot the device and then try to create the PIN again.
4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To
unjoin a desktop PC, go to Settings > System > About and select Disconnect from organization . To
unjoin a device running Windows 10 Mobile, you must reset the device.
5. On mobile devices, if you are unable to setup a PIN after multiple attempts, reset your device and start over.
For help on how to reset your phone go to Reset my phone. If the error occurs again, check the error code
against the following table to see if there is another mitigation for that error. When no mitigation is listed in
the table, contact Microsoft Support for assistance.
H EX C A USE M IT IGAT IO N
0x80090005 NTE_BAD_DATA Unjoin the device from Azure AD and

rejoin.
0x8009000F The container or key already exists. Unjoin the device from Azure AD and
rejoin.
0x80090011 The container or key was not found. Unjoin the device from Azure AD and
rejoin.
0x80090029 TPM is not set up. Sign on with an administrator account.

Click Star t , type "tpm.msc", and
select tpm.msc Microsoft Common
Console Document . In
the Actions pane, select Prepare the
TPM .
0x8009002A NTE_NO_MEMORY Close programs which are taking up

memory and try again.
0x80090031 NTE_AUTHENTICATION_IGNORED Reboot the device. If the error occurs

again after rebooting, reset the TPM or
run Clear-TPM.
0x80090035 Policy requires TPM and the device Change the Windows Hello for
does not have TPM. Business policy to not require a TPM.
0x80090036 User canceled an interactive dialog. User will be asked to try again.
0x801C0003 User is not authorized to enroll. Check if the user has permission to
perform the operation.
0x801C000E Registration quota reached. Unjoin some other device that is

currently joined using the same
account or increase the maximum
number of devices per user.
0x801C000F Operation successful, but the device Reboot the device.

requires a reboot.
0x801C0010 The AIK certificate is not valid or Sign out and then sign in again.
trusted.
0x801C0011 The attestation statement of the Sign out and then sign in again.
transport key is invalid.
0x801C0012 Discovery request is not in a valid Sign out and then sign in again.
format.
0x801C0015 The device is required to be joined to Join the device to an Active Directory
an Active Directory domain. domain.
0x801C0016 The federation provider configuration Go

is empty to http://clientconfig.microsoftonline-
p.net/FPURL.xml and verify that the file
is not empty.
0x801C0017 The federation provider domain is Go

empty to http://clientconfig.microsoftonline-
p.net/FPURL.xml and verify that the
FPDOMAINNAME element is not
empty.
0x801C0018 The federation provider client Go

configuration URL is empty to http://clientconfig.microsoftonline-
p.net/FPURL.xml and verify that the
CLIENTCONFIG element contains a
valid URL.
0x801C03E9 Server response message is invalid Sign out and then sign in again.
0x801C03EA Server failed to authorize user or Check if the token is valid and user has
device. permission to register Windows Hello
for Business keys.
0x801C03EB Server response http status is not valid Sign out and then sign in again.
0x801C03EC Unhandled exception from server. sign out and then sign in again.
0x801C03ED Multi-factor authentication is required Sign out and then sign in again. If that
for a 'ProvisionKey' operation, but was doesn't resolve the issue, unjoin the
not performed. device from Azure AD and rejoin.
Allow user(s) to join to Azure AD under
-or- Azure AD Device settings.
Token was not found in the

Authorization header.
-or-
Failed to read one or more objects.
-or-
The request sent to the server was

invalid.
-or-
User does not have permissions to join

to Azure AD.
0x801C03EE Attestation failed. Sign out and then sign in again.
0x801C03EF The AIK certificate is no longer valid. Sign out and then sign in again.
0x801C03F2 Windows Hello key registration failed. ERROR_BAD_DIRECTORY_REQUEST.

Another object with the same value for
property proxyAddresses already
exists. To resolve the issue, refer
to Duplicate Attributes Prevent
Dirsync. Also, if no sync conflict exists,
please verify that the "Mail/Email
address" in AAD and the Primary
SMTP address are the same in the
proxy address.
0x801C044D Authorization token does not contain Unjoin the device from Azure AD and
device ID. rejoin.
Unable to obtain user token. Sign out and then sign in again. Check
network and credentials.
0x801C044E Failed to receive user credentials input. Sign out and then sign in again.
Errors with unknown mitigation

For errors listed in this table, contact Microsoft Support for assistance.
H EX C A USE
0X80072F0C Unknown
0x80070057 Invalid parameter or argument is passed.
0x80090020 NTE_FAIL
0x80090027 Caller provided a wrong parameter. If third-party code

receives this error, they must change their code.
0x8009002D NTE_INTERNAL_ERROR
0x801C0001 ADRS server response is not in a valid format.
0x801C0002 Server failed to authenticate the user.
0x801C0006 Unhandled exception from server.
0x801C000B Redirection is needed and redirected location is not a well

known server.
0x801C000C Discovery failed.
0x801C0013 Tenant ID is not found in the token.
0x801C0014 User SID is not found in the token.
0x801C0019 The federation provider client configuration is empty

H EX C A USE
0x801C001A The DRS endpoint in the federation provider client

configuration is empty.
0x801C001B The device certificate is not found.
0x801C03F0 There is no key registered for the user.
0x801C03F1 There is no UPN in the token.
0x801C044C There is no core window for the current thread.
0x801c004D DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is

unable to find the default WAM account to use to request
AAD token for provisioning. Unable to enroll a device to use
a PIN for login.
Related topics
Applies to
Windows 10
This event is created when Windows Hello for Business is successfully created and registered with Azure Active
Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate
provisioning service can listen to this event and trigger a certificate request.
Event details
P RO DUC T : W IN DO W S 10 O P ERAT IN G SY ST EM
Log: Event Viewer > Applications and Service

Logs\Microsoft\Windows\User Device Registration\Admin
ID: 300
Source: Microsoft Azure Device Registration Service
Version: 10
Message: The NGC key was successfully registered. Key ID:

{4476694e-8e3b-4ef8-8487-be21f95e6f07}.
UPN:[email protected]. Attestation: ATT_SOFT. Client
request ID: . Server request ID: db2da6bd-3d70-4b9b-
b26b-444f669902da.
Server response: {"kid":"4476694e-8e3b-4ef8-8487-
be21f95e6f07","upn":"[email protected]"}
Resolve
This is a normal condition. No further action is required.
Related topics
Applies to
Windows 10
When you set up Windows Hello, the PIN or biometric gesture that you use is specific to that device. You can set
up Hello for the same account on multiple devices. If the PIN or biometric is configured as part of Windows
Hello for Business, changing the account password will not impact sign-in or unlock with these gestures since it
uses a key or certificate. However, if Windows Hello for Business is not deployed and the password for that
account changes, you must provide the new password on each device to continue to use Hello.
Example
Let's suppose that you have set up a PIN for your Microsoft account on Device A . You use your PIN to sign in on
Device A and then change the password for your Microsoft account. Because you were using Device A when
you changed your password, the PIN on Device A will continue to work with no other action on your part.
Suppose instead that you sign in on Device B and change your password for your Microsoft account. The next
time that you try to sign in on Device A using your PIN, sign-in will fail because the account credentials that
Hello on Device A knows will be outdated.
NOTE
This example also applies to an Active Directory account when Windows Hello for Business is not implemented.
How to update Hello after you change your password on another

device
1. When you try to sign in using your PIN or biometric, you will see the following message: Your password
was changed on a different device. You must sign in to this device once with your new
password, and then you can sign in with your PIN.
2. Click OK.
3. Click Sign-in options .
4. Click the Password button.
5. Sign in with new password.
6. The next time that you sign in, you can select Sign-in options and then select PIN to resume using your
PIN.
Related topics
Technology and Terms
Applies to:
Windows 10
Attestation Identity Keys
Azure AD Joined
Azure AD Registered
Certificate Trust
Cloud Deployment
Cloud Experience Host
Deployment Type
Endorsement Key
Federated Environment
Hybrid Azure AD Joined
Hybrid Deployment
Join Type
Key Trust
Managed Environment
On-premises Deployment
Pass-through Authentication
Password Hash Synchronization
Primary Refresh Token
Storage Root Key
Trust Type
Trusted Platform Module
Attestation Identity Keys

Because the endorsement certificate is unique for each device and does not change, the usage of it may present
privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem,
Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key,
which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding
certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
NOTE
The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After
it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over
the platform log state (and a monotonic counter value) at each boot by using the AIK. The AIK is an asymmetric
(public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private
portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of
operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts
a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real
TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these
facts, it will issue an AIK certificate to the Windows 10 device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an
endorsement certificate. To accommodate those devices, Windows 10 allows the issuance of AIK
cer tificates without the presence of an endorsement cer tificate. Such AIK certificates are not issued by
Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the
device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for
Business without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the
attestation process. This information can be leveraged by a relying party to decide whether to reject devices that
are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to
not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an
endorsement certificate.
Related topics
Endorsement Key, Storage Root Key, Trusted Platform Module
More information
Windows Client Certificate Enrollment Protocol: Glossary
TPM Library Specification
Return to Top
Azure AD Joined
Azure AD Join is intended for organizations that desire to be cloud-first or cloud-only. There is no restriction on
the size or type of organizations that can deploy Azure AD Join. Azure AD Join works well even in an hybrid
environment and can enable access to on-premise applications and resources.
Related topics
Join Type, Hybrid Azure AD Joined
More information
Introduction to device management in Azure Active Directory.
Return to Top
Azure AD Registered
The goal of Azure AD registered devices is to provide you with support for the Bring Your Own Device (BYOD)
scenario. In this scenario, a user can access your organization's Azure Active Directory controlled resources
using a personal device.
Related topics
Azure AD Joined, Hybrid Azure AD Joined, Join Type
More information
Introduction to device management in Azure Active Directory
Return to Top
Certificate Trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business
identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and
on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
Related topics
Deployment Type, Hybrid Azure AD Joined, Hybrid Deployment, Key Trust, On-premises Deployment, Trust Type
More information
Windows Hello for Business Planning Guide
Return to Top
Cloud Deployment
The Windows Hello for Business Cloud deployment is exclusively for organizations using cloud-based identities
and resources. Device management is accomplished using Intune or a modern management alternative. Cloud
deployments use Azure AD joined or Azure AD registered device join types.
Related topics
Azure AD Joined, Azure AD Registered, Deployment Type, Join Type
Return to Top
Cloud Experience Host

In Windows 10, Cloud Experience Host is an application used while joining the workplace environment or Azure
AD for rendering the experience when collecting your company-provided credentials. Once you enroll your
device to your workplace environment or Azure AD, your organization will be able to manage your PC and
collect information about you (including your location). It might add or remove apps or content, change settings,
disable features, prevent you from removing your company account, or reset your PC.
Related topics
Windows Hello for Business, Managed Windows Hello in Organization
More information
Windows Hello for Business and Device Registration
Return to Top
Deployment Type
Windows Hello for Business has three deployment models to accommodate the needs of different
organizations. The three deployment models include:
Cloud
Hybrid
On-Premises
Related topics
Cloud Deployment, Hybrid Deployment, On-premises Deployment
More information
Return to Top
Endorsement Key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is
a pair of asymmetric keys (RSA size 2048 bits).
The endorsement key public key is generally used for sending securely sensitive parameters, such as when
taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used
when creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM.
The endorsement key is often accompanied by one or two digital certificates:
One certificate is produced by the TPM manufacturer and is called the endorsement cer tificate . The
endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM
manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement
certificate is created during manufacturing or the first time the TPM is initialized by communicating with an
online service.
The other certificate is produced by the platform builder and is called the platform cer tificate to indicate
that a specific TPM is integrated with a certain device.
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is
created when the TPM is initialized during the OOBE of Windows 10.
Related topics
Attestation Identity Keys, Storage Root Key, Trusted Platform Module
More information
Understand the TPM endorsement key.
Return to Top
Federated Environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises
directory objects are synchronized with Azure Active Directory and users accounts are managed on-premises.
With AD FS, users have the same password on-premises and in the cloud and they do not have to sign in again
to use Office 365 or other Azure-based applications. This federated authentication model can provide additional
authentication requirements, such as smart card-based authentication or a third-party multi-factor
authentication and is typically required when organizations have an authentication requirement not natively
supported by Azure AD.
Related topics
Hybrid Deployment, Managed Environment, Pass-through authentication, Password Hash Sync
More information
Choosing the right authentication method for your Azure Active Directory hybrid identity solution
Return to Top
Hybrid Azure AD Joined

For more than a decade, many organizations have used the domain join to their on-premises Active Directory to
enable:
IT departments to manage work-owned devices from a central location.
Users to sign in to their devices with their Active Directory work or school accounts. Typically, organizations
with an on-premises footprint rely on imaging methods to provision devices, and they often use or group
policy (GP) to manage them.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided
by Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both,
joined to your on-premises Active Directory and your Azure Active Directory.
Related topics
Azure AD Joined, Azure AD Registered, Hybrid Deployment
More information
Return to Top
Hybrid Deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud
resources that are accessed using a managed or federated identity that is synchronized with Azure Active
Directory. Hybrid deployments support devices that are Azure AD registered, Azure AD joined, and hybrid Azure
AD joined. The Hybrid deployment model supports two trust types for on-premises authentication, key trust and
certificate trust.
Related topics
Azure AD Joined, Azure AD Registered, Hybrid Azure AD Joined,
More information
Return to Top
Join type
Join type is how devices are associated with Azure Active Directory. For a device to authenticate to Azure Active
Directory it must be registered or joined.
Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure
AD device registration provides the device with an identity that is used to authenticate the device when a user
signs-in to Azure AD. You can use the identity to enable or disable a device.
When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device
attributes in Azure AD are updated with additional information about the device. This allows you to create
conditional access rules that enforce access from devices to meet your standards for security and compliance.
For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune .
Joining a device is an extension to registering a device. This means, it provides you with all the benefits of
registering a device and in addition to this, it also changes the local state of a device. Changing the local state
enables your users to sign-in to a device using an organizational work or school account instead of a personal
account.
Related topics
Azure AD Joined, Azure AD Registered, Hybrid Azure AD Joined
More information
Return to Top
Key Trust
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active
Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows
Server 2016 domain controllers.
Related topics
Certificate Trust, Deployment Type, Hybrid Azure AD Joined, Hybrid Deployment, On-premises Deployment,
Trust Type
More information
Return to Top
Managed Environment
Managed environments are for non-federated environments where Azure Active Directory manages the
authentication using technologies such as Password Hash Synchronization and Pass-through Authentication
rather than a federation service such as Active Directory Federation Services.
Related topics
Federated Environment, Pass-through authentication, Password Hash Synchronization
Return to Top
On-premises Deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises
resources that are accessed using Active Directory identities. On-premises deployments support domain joined
devices. The on-premises deployment model supports two authentication trust types, key trust and certificate
trust.
Related topics
Cloud Deployment, Deployment Type, Hybrid Deployment
More information
Return to Top
Pass-through authentication
Provides a simple password validation for Azure AD authentication services using a software agent running on
one or more on-premises servers to validate the users directly with your on-premises Active Directory. With
pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with
Office 365 and manage your users on-premises. Allows your users to sign in to both on-premises and Office
365 resources and applications using their on-premises account and password. This configuration validates
users' passwords directly against your on-premises Active Directory without sending password hashes to Office
365. Companies with a security requirement to immediately enforce on-premises user account states, password
policies, and logon hours would use this authentication method. With seamless single sign-on, users are
automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate
network.
Related topics
Federated Environment, Managed Environment, Password Hash Synchronization
More information
Return to Top
Password Hash Sync

The simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash
sync (PHS), you synchronize your on-premises Active Directory user account objects with Office 365 and
manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active
Directory to Azure AD so that the users have the same password on-premises and in the cloud. When
passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that
your users can always use the same password for cloud resources and on-premises resources. The passwords
are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as
Identity Protection, require PHS regardless of which authentication method is selected. With seamless single
sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected
to your corporate network.
Related topics
Federated Environment, Managed Environment, Pass-through authentication
More information
Return to Top
Primary Refresh Token

SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to
obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using
Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a
Primary Refresh Token (PRT). This is a JSON Web Token containing claims about both the user and the device.
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is
obtained. This is true for both Azure AD joined and hybrid Azure AD joined devices. In personal devices
registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device
the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com,
outlook.com, etc.).
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications
every time. Please also note that the PRT contains information about the device. This means that if you have any
device-based conditional access policy set on an application, without the PRT, access will be denied.
Return to Top
Storage Root Key

The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK
has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK
key is created when the ownership of the TPM is taken.
Related topics
Attestation Identity Keys, Endorsement Key, Trusted Platform Module
More information
Return to Top
Trust type
The trust type determines how a user authenticates to the Active Directory to access on-premises resources.
There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models
support both trust types. The trust type does not affect authentication to Azure Active Directory. Windows Hello
for Business authentication to Azure Active Directory always uses the key, not a certificate (excluding smart card
authentication in a federated environment).
Related topics
Certificate Trust, Hybrid Deployment, Key Trust, On-premises Deployment
More information
Return to Top
Trusted Platform Module

A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on
that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the
time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with
each other:
The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under
ISO / IEC 11889 standard.
The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by
the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys for
BitLocker, Windows Hello, virtual smart cards, and other public key certificates. For more information, see TPM
requirements in Windows 10.
Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and
modern security features, Windows 10 supports only TPM 2.0.
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
Update cryptography strength to meet modern security needs
Support for SHA-256 for PCRs
Support for HMAC command
Cryptographic algorithms flexibility to support government needs
TPM 1.2 is severely restricted in terms of what algorithms it can support
TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
Consistency across implementations
The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
TPM 2.0 standardizes much of this behavior
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers,
RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single
component:
A RSA 2048-bit key generator
A random number generator
Nonvolatile memory for storing EK, SRK, and AIK keys
A cryptographic engine to encrypt, decrypt, and sign
Volatile memory for storing the PCRs and RSA keys
Related topics
Attestation Identity Keys, Endorsement Key, Storage Root Key
More information
Return to Top
Windows Hello for Business Videos
Applies to
Windows 10
Overview of Windows Hello for Business and Features

Watch Pieter Wigleven explain Windows Hello for Business, Multi-factor Unlock, and Dynamic Lock
Why PIN is more secure than a password

Watch Dana Huang explain why a Windows Hello for Business PIN is more secure than a password.
Microsoft's passwordless strategy

Watch Karanbir Singh's Ignite 2017 presentation Microsoft's guide for going password-less
Windows Hello for Business Provisioning

Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business provisioning works.
Windows Hello for Business Authentication

Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business authentication works.
Windows Hello for Business user enrollment experience

The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello
for Business policy settings to your environment.
Windows Hello for Business forgotten PIN user experience

If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.
Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot
my PIN" link on the PIN credential provider.
For on-premises deployments, devices must be well connected to their on-premises network (domain
controllers and/or certificate authority) to reset their PINs. Hybrid customers can on-board their Azure tenant to
use the Windows Hello for Business PIN reset service to reset their PINs without access to their corporate
network.

Windows Hello For Business

Uploaded by

Copyright:

Available Formats

Windows Hello For Business

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows Hello For Business

Uploaded by

Copyright:

Available Formats

What are the main authentication methods supported by Windows Hello for Business?

What are the main authentication methods supported by Windows Hello for Business?

What are some of the advantages of using a PIN instead of a password for authentication?

What are some of the advantages of using a PIN instead of a password for authentication?

Contents

Windows Hello for Business documentation

Windows Hello addresses the following problems with passwords:

The difference between Windows Hello and Windows Hello for

Benefits of Windows Hello

How Windows Hello for Business works: key points

Comparing key-based and certificate-based authentication

Four steps to password freedom

1. Develop a password replacement offering

Validate that passwords and Windows Hello for Business work

The Road Ahead

PIN is tied to the device

PIN is local to the device

PIN is backed by hardware

PIN can be complex

What if someone steals the laptop or phone?

Why do you need a PIN to use biometrics?

How does Windows Hello work?

Why should I let my employees use Windows Hello?

Where is Windows Hello data stored?

Has Microsoft set any device requirements for Windows Hello?

Technical Deep Dive

For more information read how provisioning works.

For more information read how authentication works.

Azure AD joined in Managed environments

A The most common way Azure AD joined devices register

B The application builds a sign-in request for the authorization

D The application looks for MDM terms of use (the

E The application sends a device registration discovery request

F The application creates TPM bound (preferred) RSA 2048 bit

G The application sends a device registration request to Azure

H Device registration completes by receiving the device ID and

Azure AD joined in Federated environments

A The most common way Azure AD joined devices register

B The application builds a sign-in request for the authorization

D The application POST the credential to the on-premises STS,

E The application looks for MDM terms of use (the

F The application sends a device registration discovery request

G The application creates TPM bound (preferred) RSA 2048 bit

H The application sends a device registration request to Azure

I Device registration completes by receiving the device ID and

Hybrid Azure AD joined in Managed environments

A The user signs in to a domain joined Windows 10 computers

B The task queries Active Directory using the LDAP protocol

C For the managed environment, the task creates an initial

D The computer cannot authenticate to Azure DRS until a

G The task sends a device registration request to Azure DRS

H Device registration completes by receiving the device ID and

Hybrid Azure AD joined in Federated environments

A The user signs in to a domain joined Windows 10 computers

B The task queries Active Directory using the LDAP protocol

C For the federated environments, the computer authenticates

D The application creates TPM bound (preferred) RSA 2048 bit

E To provide SSO for on-premises federated application, the