[MUSIC]
Matthew Palko: Hi. I’m Matthew Palko, a Program Manager in
Enterprise and Security.
Ravi Vennapusa: And I’m Ravi Vennapusa, a Program Manager
in the Azure AD team.
Matthew: Today, we’re going to provide an in-depth look into
how Windows Hello for Business provisioning works.
Ravi: Windows Hello, as you may know, is Microsoft’s
premiere passwordless solution for devices where the user
and device share one to one relationship. Each user on the
device gets that one prior key that is authorized by a simple
gesture, a PIN, face, or fingerprint. Every authentication
with Windows Hello for Business is two factors, with one
gesture being position of the private key and the other
being the gesture used to authorize it.
Matthew: Whether your organization is cloud only 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 or
hybrid Azure Active Directory joined devices. Windows Hello
for Business also works for pure on-prem domain joined
devices.
Ravi: That’s right. With Windows Hello for Business, we aim
to provide flexibility and deployment options so that all
organizations can deploy and start on a journey to becoming
passwordless. Windows Hello for Business supports two
deployment models—key trust and certificate trust deployments.
Matthew, can you help us understand the differences between
these deployment models?
Matthew: Sure. Key trust or certificate trust refer to the
credential that the end user provisions and how they
authenticate on-premises. In both trust models, a private
and public key pair will be created for the user. In the key
trust deployments, the user will receive a self-signed
certificate with their public key and in the certificate trust
case, the self-signed certificate is replaced by a certificate
issued from your organization’s public key infrastructure.
Ravi: And do the different trust models affect how someone
would deploy Windows Hello for Business and what scenarios
are supported?
Matthew: The trust type of your deployment affects both of
those things. Scenarios that require a certificate like legacy
applications that use certificate based auth, client based
TLS or remote desktop protocol will work with your certificate
trust credential but will not work with a key trust credential.
One alternative though is that Windows Hello for Business
supports importing other certificates or creation of other
credentials that are protected by your existing Windows
Hello for Business gestures. So, you could deploy key trust
and then deploy additional certificates to support the extra
scenarios that you need.
Ravi: You also said that this trust type decision affects how
provisioning works. Can you elaborate on that?
Matthew: Of course. For this, I think we should dive into
the mechanics of provisioning.
This can be basically broken into two phases—device
registration and then provisioning of the Windows Hello for
Business credential.
Ravi: By device registration, do you mean joining your device
to Azure AD or on-prem AD?
Matthew: Yeah. That’s a prerequisite for deploying Windows
Hello for Business. For the sake of time, let’s leave out the
device registration and just focus on the Windows Hello for
Business part.
Windows Hello for Business provisioning can be broken down
itself into a few different parts—authentication and MFA, key
generation, and key registration.
There are two additional phases that can occur depending
on your joint type and your trust type. The fourth phase,
key sync, will occur for hybrid deployments, but it’s not
needed for Azure only or on-premise only deployments.
And the fifth phase is certificate enrollment, which is only
going to occur for cert trust deployments.
When a user starts enrollment for a Windows Hello for
Business credential, the first thing we need them to do is
authenticate and prove who they are. We also want them
to MFA.
Ravi: That’s important to remember. Windows Hello for
Business is a two-factor credential and so we do not want to
provision it without the user providing multiple factors. So,
Matthew, can you explain how authentication differs based
on the environment, whether it’s on-prem only, cloud only,
or hybrid?
Matthew: For Azure AD only deployments, the identity
provider for these devices will be Azure AD. The user will
authenticate to Azure AD with an Azure AD credential,
which in most cases will be their password and complete
MFA using the Azure MFA service, as shown in your slides.
For on-prem only deployments, the identity provider for
these devices will be AD FS. The user will authenticate to
AD FS and then does MFA using the Azure MFA plug-in or
a third party MFA plug-in. AD FS would replace the
authentication service which is shown in this slide.
For hybrid deployments, authentication in MFA can occur
in a few different ways. If you have a federated environment,
then your user will authenticate an MFA using AD FS, the
same as in the on-prem case. If your hybrid environment
does not have AD FS, then authentication and MFA will
occur directly with Azure AD, just like in the Azure only
case.
For hybrid and cloud only deployments, the result of all
these authentications is that the user’s going to get back
a token for the Azure device registration service with an
MFA claim that we can later use to register the Windows
Hello for Business public key to the directory.
In on-premises only where AD FS was used, the device gets
back an enterprise auth token.
Ravi: After the device gets back the token, the user will be
prompted to set their Windows Hello for Business gesture.
This tip is the same for every deployment model, whether
it’s on-premises only, cloud only, or hybrid. To improve
security, the MFA lifetime during Windows Hello for Business
setup is designed to be short lived so that the internal user
is setting it up. If MFA was done more than 10 minutes ago,
the user will be reprompted to do MFA during Windows
Hello for Business setup.
Matthew: Underneath the covers when the user is setting
up their gesture, the user’s Windows Hello for Business
public private key pair is going to be generated in the TPM.
Once the key pair is created, the public key needs to be
registered with the directory, so it can be used for
authentication. In the Azure only case, the public key is
sent to the Azure device registration service along with the
ADRS token, proving that the user auth’d and MFA’d before.
The Azure Device Registration Service writes that key to
the user object in Azure AD. All hybrid deployments are
going to follow this Azure case. The key will always be
written to Azure AD first. But because the key is needed
in both Azure AD and in AD to support hybrid scenarios,
the key will then get written back down to AD to a user
attribute called the MSDS key credential link. Key writeback
is handled by Azure AD Connect during the normal sync
cycle. For the on-prem only case, the key needs to be
registered directly with AD. In this scenario, the key
registration role is handled by AD FS. The client will send
the new public key to AD FS with the enterprise auth token
and AD FS will write that key to the user object. For key
trust deployments at this point, provisioning is done.
Ravi: But if you’re doing cert trust deployment, there’s one
additional thing that needs to happen, which is the
certificate enrollment. The client will generate a certificate
request after registering the key. This certificate request is
then sent to the certificate registration authority, which
usually is your AD FS. AD FS will validate the signature over
the certificate request using the key that has been
registered and will fulfill the request using your on-premises
certificate authority. In cases where the device is Azure
AD joined and enrolled into Intune, the certificate can also
be deployed via Intune using SCEP and NDES.
Once the certificate is enrolled on the device, Windows
Hello provisioning is complete.
Matthew: That’s basically it for provisioning. Remember, in
both cases, the core steps are authenticate an MFA, key
generation, key registration, and then the optional key
sync and certificate enrollment steps. For more information
on provisioning and for understanding all the infrastructure
needed to deploy, we recommend taking a look at our
documentation and deployment guides at aka.ms/WHFB.
Ravi: Thanks for joining us. Watch our next video covering
authentication with Windows Hello for Business.
[MUSIC]