[MUSIC]
Matthew Palko: Hi. I’m Matthew Palko, a Program Manager in
the Enterprise and Security team.
Ravi Vennapusa: And I’m Ravi Vennapusa, a Program Manager
in the Azure AD team.
In a previous video, we covered the different deployment
models for Windows Hello for Business and how it is provisioned
on device. In this video, we will cover how Windows Hello
for Business is used to log on and access resources.
Matthew: To quickly recap, Windows Hello for Business
supports cloud only, on-premise only, and hybrid deployments.
In all these configurations, a user will provision a private
public key pair as their credential that is protected by a
simple user gesture, a PIN, a face, or a fingerprint. If the
user only has the key as their credential, we refer to this
configuration as key trust. If they also have a certificate
issued from their company’s public key infrastructure, we
refer to it as certificate trust.
Using Hello for Business as a credential can be broken down
into two main flows—authentication to Azure Active Directory
and authentication to Active Directory. These two flows can
occur during logon or when trying to access a specific
resource. Ravi, can you explain how Windows Hello for
Business works on Azure AD joined devices?
Ravi: Sure. Almost all authentication scenarios in Windows
start with a credential provider and Windows Hello for
Business is no different.
On the lock screen, credential providers are represented by
small square icons showing the user their available
authentication options. In the case of Windows Hello for
Business, credential providers will be used to collect the
user’s PIN, face, or fingerprint. When a user provides their
gesture to the appropriate credential provider, it will verify
that the gesture matches one registered by the user. If the
gesture is correct, the credential provider will get back a
ticket from the Windows Hello Service that can be redeemed
for a signature operation. This ticket is passed to Win Logon,
which essentially loads the credential providers and is also
responsible for loading the user profile after a successful
logon. Win Logon will then pass the credentials to the local
security authority or LSA for short, which will complete the
authentication process. During authentication to Azure AD,
the LSA will leverage a component called the Cloud
Authentication Security Support Provider or Cloud AP for
short to communicate with Azure AD. The LSA will pass the
ticket from Windows Hello to Cloud AP. When Cloud AP
receives them, it will request a cryptographic nonce from
Azure AD. This is an arbitrary random number that is used
to ensure that old authentications to Azure AD
can’t be reused.
Cloud AP will request that the Windows Hello for Business
stack signs the nonce with the user’s private key that was
provisioned during registration. The signed nonce will be
returned by Cloud AP to Azure AD, which will use the
public key that the user registered during provisioning
to confirm that the nonce was indeed signed by the correct
private key. A register key was used, Azure will generate a
primary fresh token or PRT for the user and send it back to
the device. The PRT will be cached by the LSA so that it can
be used in future authentication requests to Azure AD and
also enable single sign-on to any Azure AD resources.
Now, the LSA will notify Win Logon that authentication
occurred successfully and Win Logon will load the user’s
profile. The user will land on the desktop and can access
any cloud resources that they need to get their things done
using the PRT alone.
One important note to make about authenticating to Azure
with Windows Hello for Business is that a certificate is never
involved. This authentication is purely key based even in
cases where a user has been issued a Windows Hello for
Business certificate.
Now, let’s take a look at how Windows Hello authentication
works on a hybrid Azure AD joined device.
Matthew, can you explain how the authentication works on
hybrid Azure AD joined devices?
Matthew: Sure. In this scenario, the logon flow is going to
differ from an Azure AD joined one because the primary
identity provider for this device is on-premise AD. These
devices need to authenticate to a domain controller in order
to log in and access on-premise resources. The same is true
of domain joined devices, where there is no Azure AD
presence. For hybrid Azure AD joined devices, the logon flow
will look very similar to traditional smart card authentication
to a domain controller and will use the Kerberos protocol.
Windows Hello for Business will package its authentication
request to the domain controller the same way Windows would
package a smart card authentication request. This flow starts
the same as the Azure AD joined case, where a credential
provider will collect one of the user’s Windows Hello for
Business gestures and verify it with the Windows Hello
Service. It will get back a ticket from the service and pass
it down to the local security authority. In the on-premises
case because we want to authenticate to the domain controller
with Kerberos instead of Azure AD, the ticket is passed to a
component called the Kerberos provider instead of Cloud AP.
The Kerberos provider will use a domain hint to locate a
domain controller that will act as the key distribution center
or KDC role in the Kerberos protocol. It will use the ticket it
got to then sign Kerberos preauthentication data, which with
the user’s Windows Hello for Business private key. The
provider then sends the signed preauthentication data to the
domain controller along with the certificate for the user’s
Windows Hello for Business public key and a message
known as an AS_REQ. This message is specific to the
Kerberos protocol and contains information needed to
properly complete the authentication.
Ravi: So, Matthew, what do you explain was key trust? How
is it going to be different than cert trust?
Matthew: In the case of the certificate trust deployment,
the certificate provided in the AS_REQ will be a user
certificate issued to the user by their enterprise’s public
key infrastructure. If they are using key trust instead, the
certification will be a self-signed certificate generated by
the system.
When the domain controller receives the AS_REQ, it will
attempt to validate the certificate provided in the request.
For certificate trust, the DC will be able to validate this
because the certificate chains through a trusted root
certificate authority. It will retrieve the public key and user
principal name from the cert, and it can then validate the
signature over the preauth data using the public key and
verify that the UPN in the cert is also in Active Directory.
In the case of key trust, the certificate is self-signed and it
doesn’t chain to a trusted root. If the domain controller sees
that the certificate is self-signed, it will look up the public
key in the certificate in AD and validate that this is registered
to the user who’s attempting to authenticate. The DC trust
that the user authenticated and MFA’d when the key was
registered and it will use that to validate the signature over
the preauth data. The logic to handle looking up the public
key and trusting that it was registered properly was added to
Windows Server 2016, which is why key trust requires 2016
or new domain controllers in your environment.
Once the domain controller confirms the validity of the AS_REQ,
it will generate a ticket granting ticket or TGT, which can be
used for future authentication requests to the KDC. That gets
sent back to the client in another Kerberos message called
an AS_REP. The Kerberos provider on the client also
needs to verify that the message it received is valid. It
will use the KDC certificate which was included in the AS_REP
to do this. The Kerberos provider will verify the KDC
certificate chains to a trusted root and that it is for the
correct domain that the user is trying to authenticate to.
It will then pass the TGT to the local security authority,
which will then cache it for future authentication requests
from the client. For future authentication to on-premise
resources, the TGT can be used without the user having
to provide a gesture, giving them SSO to any on-premise
resources. LSA will then notify when logon of the successful
authentication, which will load the user’s profile and allow
them onto the desktop.
The same flow that was used to login on an Azure AD
device also happens on a hybrid Azure AD joined device
and this is usually going to happen immediately following
this logon flow that I just went through.
Ravi: One important thing to remember is that in the case
of an Azure AD joined device, this on-premises authentication
flow happens on demand when a user is trying to access
an on-prem resource. So, on-premise authentication can
work even if the device itself is not joined to on-premises
Active Directory as a credential is a user attribute.
That’s it for authentication for Windows Hello for Business
to both Azure AD and on-premises AD. Whether using key
or certificate trust, a user should be able to authenticate
to Azure AD and on-premises AD if your infrastructure is
configured properly. This will result in a user getting a PRT
and a TGT, which enables seamless access to both cloud
and on-prem resources.
I hope this was helpful for you to understand how Windows
Hello for Business works in both provisioning and
authentication.
Matthew: Thanks for joining us. For more information, please
take a look at our documentation at aka.ms/WHFB.
[MUSIC]