Something that has come up recently in my conversations with you has been how Windows Hello for Business works behind the scenes. I am very excited as more organizations are looking into deploying Windows Hello for Business and some even trying to go password-less. I’ll use this short post to explain how the credential is provisioned and how is it used upon authentication in Windows.

Provisioning

Windows 10 devices that are joined (hybrid Azure AD joined, or Azure AD joined) will provision this credential upon user first logon, when the user is provisioning the Windows Hello for Business gesture (PIN, fingerprint, facial recognition) (there are more details about when this happens in this post). I won’t get into the details of the experience but will rather go in detail on what keys are generated, how they are used and what state is stored in the directory.

(1) Before the user provisions the gesture, the following has been generated in the device:

• The Attestation Identity Key or AIK certificate. Let’s call it AIK-cert.
• A private-public key pair (RSA 2048 bit) representing the new credential that will be associated with the user, and its corresponding attestation blob (which attests that the key has been generated in the TPM of the device). Let’s call it Kuser (Kuser-pri or Kuser-pub depending on the context).

(2) Also, the following has been provisioned previously as part of device registration (when the device become joined to Azure AD):

• A private-public key pair registered to the device (in addition to the device certificate key) that is going to be used to protect SSO tokens on the device by storing authentication session keys in the TPM, usually referred as storage key. The private portion of the key stays at the TPM of the device while the public portion was provisioned in Azure AD against the device object representing the device. Let’s call it Kstk (Kstk-pri or Kstk-pub).

(3) When the user provisions the gesture the following occurs:

• The user must have provided multi-factor authentication (MFA). The device gets an access token to Azure DRS using this authentication.
• The Kuser-pri is cryptographically protected to the gesture the user provisioned (this is what we usually have called a virtual container, where the key is put, being the gesture the key that opens the container).
• The Kuser-pub along with the key attestation blob, the AIK-cert, and the access token are sent to Azure DRS for registration of the key.
• Azure DRS validates the access token and uses the AIK-cert to validate the attestation blob of Kuser (this validates that the key was generated on a valid TPM).
• The Kuser-pub is registered to the user object in Azure AD and it is associated with the device object.
• Azure DRS returns a key ID to the client which the client stores.

(4) If certificate-based provisioning via AD FS has been enabled, for on-premises SSO, the following happens:

• A certificate signing request is sent to AD FS. AD FS acts as a Registration Authority (RA) and tells the Certificate Authority (CA) in the enterprise to issue the certificate.

Authentication

Upon sign-in to Windows, when the user enters the gesture to unlock the credential, the following happens:

1. The Cloud Authentication Provider plug-in for Azure AD (a.k.a. client) sends a “hello” request to Azure AD. This is basically an empty OAuth request, to which Azure AD responds with a nonce valid for 5 minutes.
2. Client signs the nonce with Kuser-pri and sends an authentication request to Azure AD with it.
3. Azure AD verifies the signature of the payload using the registered previously Kuser-pub in the user object. After verification of the signature, it verifies the nonce.
4. Azure AD replies with the Primary Refresh Token (PRT) and includes a symmetric service key encrypted using the Kstk-pub (the one created and provisioned during device registration).
5. Client decrypts and imports service key into TPM using the Kstk-pri.

Once the PRT is obtained and the user wants to have access to an application the following happens (this is true regardless of how the PRT was obtained, including using username and password):

1. The Web Account Manager plug-in for Azure AD (a.k.a. client) derives a new service key from the previous service key Ksk using a ‘salt’. Let’s call it Ksk’.
2. The client sends the ‘salt’ and the authentication request for an access token signed with the new Ksk’.
3. Azure AD verifies signature and derives a new key with a new ‘salt’. Let’s call it Ksk’’. It sends the access token back to the client signed by the Ksk’’, including the ‘salt’.
4. Client verifies signature and gets access token.

Authentication and hybrid Azure AD joined devices

There are some considerations during authentication for hybrid Azure AD joined devices (on-premises domain joined that are registered with Azure AD) that you may find interesting to have in mind when deploying Windows Hello for Business.

Let’s see where this happens in the authentication flow. Remember the picture below from this post? (Notice now that the picture has been slightly adjusted to reflect Windows Hello for Business.)

For hybrid Azure AD joined devices the left part (Kerberos auth) happens first. Given how Kerberos auth works, if a user certificate for the Hello credential has not been provisioned, the first authentication of that user with the Hello gesture will fail and the user won’t have access to the device. No cloud authentication happens either, so no PRT is obtained.

If a Hello certificate has been provisioned, the first sign in of the user with the Hello gesture must occur within line of sight to a domain controller (DC). In other words the user must be physically on-premises, or must have a connection to the corporate network via VPN (after being signed in using username/password) and unlocking the device using Hello. Once the user has signed in to the device, cached logon will allow the user to get access to the device if the user is outside of the network.

• Note that you can force the user to do a full network authentication every now and then to block access to the device, but this will require the user to come to the corporate network as often as you require so.

Once the Kerberos auth succeeds (either via full network or cached logon) the device will authenticate the Hello key against Azure AD every 4 hours to obtain a new PRT. Please note that unlike username/password, authentication of Hello doesn’t require going to AD FS (in a federated configuration) as all that Azure AD is proving is that the device has possession of the private key.

Remember that the credential is NOT in Azure AD or AD on-prem, the credential never leaves the device, and all Azure AD needs, is making sure the device really holds that credential. This is different from the username/password case where the actual credential is in Azure AD or AD on-prem, therefore to validate it, the full credential needs to flow through the network for validation. In a federated configuration this means that AD FS needs to be in the auth path to verify the credential with AD on-prem.

Securing your authentication with Azure AD

For securing your authentication you should have in mind the following considerations:

1. Always protect your applications and resources with MFA- and device-based Azure AD conditional access. Remember that Windows Hello for Business is a strong credential that fulfills MFA.
2. In addition you can protect them using risk-based conditional access with Azure AD Identity Protection.
3. In the case you need to revoke access to a given user who has provisioned Windows Hello for Business you can:
   1. Disable the user and/or device in Azure AD.
   2. Revoke user tokens.

Well, that’s it for now. I hope this post will help with your security reviews and just about learning how Windows Hello for Business works. Please let me know your questions or thoughts!

Jairo (Twitter: @JairoC_AzureAD)