Windows Hello for Business: Registration and Authentication with #AzureAD

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.)

SignInFlowWinHello

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)

This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to Windows Hello for Business: Registration and Authentication with #AzureAD

  1. Pirmin Felber says:

    Hi Jairo
    Thanks for this again great article!
    I’m wondering how the process looks like if a device, where a user is provisioned for Windows Hello for Business, gets lost / gets stolen. I realize private Keys required to sign in a user form that device are protected by the TPM and can only be unlocked through the users Windows hello for business gesture – so not much risk about a stolen device. However, I still wonder if it is possible to block a device from being used to authenticate any user through Windows hello for business: If my Identity Provider is AzureAD I simply disable the device and the user won’t get a new PRT from AzureAD using Windows Hello for business.
    But if I also use Windows Hello for Business for ADDS (Kerberos)? With the certificate-trust model I can at least revoke the user’s certificate which was issued trough ADFS when the client was provisioned (and publish/expire CRL). With key-trust model, I thought that disabling the device (disable the computer Obj, sync to AzureAD, write-back device Obj) would be sufficient. But even after hours the user can still sign-in. Am I missing something?

    best regards & thanks for your help
    Pirmin

    Like

    • Jairo says:

      Hi Pirmin,

      You are right about the ways you can disable access to Azure AD or on-prem access if using the cert-trust model.

      To disable on-prem access on the key-trust model you will need to delete the public key registered with the user who reported the device lost (that corresponds to the key in such device). Now, that is not an easy task, and for that the team is considering better management tools to accomplish so.

      One way (not optimal) is to delete all keys on the user on-prem (msDS-KeyCredentialLink attribute on the user account). This will block any access from that device, but also from other devices where the user has provisioned Windows Hello for Business. This means that the user will need to re-provision Windows Hello for Business on those other devices.

      Each entry in the msDS-KeyCredentialLink attribute has a pointer to the device ID where the key is. The value of each entry in this attribute is a blob that needs some processing to get the key information including the device ID. This is where the management tools the team have been thinking about will help.

      Jairo

      Like

  2. Tom Haller says:

    Thank you Jairo for your insights into this topic. We are currently stuck with trying to implement WHFB on AAD-joined devices only (hybrid works fine). Do you have any hints, how we can “debug” the whole certification process?

    Like

    • Jairo says:

      Hi Tom,

      In general to debug device registration, WHfB registration or authentication of the user with Azure AD in Windows (SSO and access), what I would suggest is first relying on dsregcmd.exe /status to check the registration status of the device and the authentication status of the user. AzureAdJoined:YES will tell you whether the device is registered, NgcSet:YES will tell you that the user has provisioned WHfB correctly and AzureAdPrt:YES will tell you whether the user has authenticated to Azure AD successfully upon Windows sign-in.

      You can also check Event Viewer to check for any failures upon 1) registration of device, 2) registration of WHfB or 3) authentication of the user. For 1 and 2 you should check the ‘User Device Registration’ node and for 3 you should check the ‘AAD’ node, both under ‘Application and Services Logs’ > ‘Microsoft’ > ‘Windows’.

      That would be a start.

      Jairo

      Like

  3. Hi,
    Is it possible to use a third party MDM provide to deliver the cert to the device for use in cert-auth method or does it have to come from ADFS? The cert is coming from our on-prem MS CA and configured with all the correct settings (smart card, schema on 2016, etc), but I still get this error in HelloForBusiness event viewer:
    “Windows Hello for Business failed to locate a certificate payload for the sign-in certificate. The SCEP Request is not available.” EventID 7209

    This is a cloud-only joined windows 10 system. Key-trust method works, but not cert trust.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s