Azure AD Mailbag: Windows Hello for business
Published Apr 12 2019 09:00 AM 26.4K Views
Microsoft

Greetings! It’s another Friday, so it’s time for another Azure AD mailbag and today we’ll be looking at Windows Hello questions. It is my favorite and most used form of authentication on my Surface devices. Windows Hello is one of the strongest forms of authentication while being the most convenient for me... how cool is that?

-Sue Bohn

---

Hi all. I’m Karam Masri from the Azure AD Get-To-Production team. I’ve been working with some of our enterprise customers on the deployment of Windows Hello for Business as part of their strategy to go passwordless. In this post I want to share some of the lessons learned during those deployments.

 

Q1: Which common symptoms are my users going to experience that will indicate I have missed some of the steps to deploy Windows Hello for Business.

The most common symptoms are that users with Azure AD Joined or Hybrid Azure AD Joined Windows 10 computers that have enrolled in Windows Hello for Business will not be able to access corporate resources. Some of these symptoms are:

  • Users in Azure AD Joined computers that logged on to Windows using Windows Hello for Business are prompted for username and password when accessing on-premises resources (like file shares)
  • Users in Hybrid Azure AD Joined computers cannot log on to Windows using Windows Hello for Business credentials

Q2: Which of the steps that are commonly missed cause these symptoms?

There are several possible causes for these symptoms:

  • The Azure AD Connect schema has not been refreshed after upgrading the AD schema to Windows Server 2016
  • The account used by the sync engine to connect to AD doesn’t have permissions over the attributes used to store Windows Hello for Business credentials
  • Domain controllers missing certificates required for Windows Hello for Business

 

Q3: I upgraded the AD schema to Windows Server 2016 after Azure AD Connect was deployed. Why do I have to refresh the Azure AD Connect schema?

The installation of Azure AD Connect adds the synchronization rules to write-back the Windows Hello for Business credentials (msDs-KeyCredentialslLink attribute) to on-premises if the version of the AD schema is Windows Server 2016 or higher at the time of installation. These rules are not added if the version of the schema is below Windows Server 2016 when the Azure AD Connect wizard is being run.
Note that the requirement in this scenario is the version of the AD schema, independently of the version of Windows on the domain controllers.

To refresh the Azure AD Connect schema, rerun Azure AD Connect and choose the option “Refresh directory schema”. This option will let the installation wizard know that the attributes used by Windows Hello for Business exist now in the AD schema and then it will add the rules to synchronize them.

 

Hello1.png

 

Q4: How do I know that the Azure AD Connect schema refresh worked and the attributes used by Windows Hello for Business are being synchronized?

Before the schema was refreshed:

  • The msDs-KeyCredentialslLink attribute will be empty for users that have provisioned Windows Hello for Business credentials
  • The Synchronization Rules Editor will not list any outbound rules to on-premises AD named “Out to AD – User NGCKey”.

After the Azure AD Connect schema is refreshed and at least one sync cycle has completed successfully:

  • Users with provisioned Windows Hello for Business credentials will have the msDs-KeyCredentialslLink attribute populated in on-premises AD.
  • There will be an outbound synchronization rule named “Out to AD – User NGCKey” (one rule per-synchronized forest).

 

hello2.png

 

Q5: I have refreshed the Azure AD Connect schema, but still see that the msDs-KeyCredentialslLink attribute is not being synchronized and I started getting synchronization errors of type “Permissions-issue”

Similar to the previous cause, if Azure AD Connect was deployed before the AD schema was upgraded to Windows Server 2016 then the sync account used to connect to AD will not have permissions over the attribute used by Windows Hello for Business (msDs-KeyCredentialslLink).  

 

To fix these permissions, use Active Directory Users and Computers (or any other tool that allows to set permissions over AD objects) to grant Read/Write permissions over the msDs-KeyCredentialslLink to the sync account used by Azure AD Connect in each domain that is synched. The permissions should be set at the top of each domain and apply to Descendant User Object.

 

hello3.png

 

Scroll down on the permissions list to make sure that the account is granted read and write permissions over the msDS-KeyCredentialLink attribute:

 

hello4.png

 

Q6: How do I know that these permissions worked? 

Before the permissions are set:

  • The synchronization engine will report errors of type “Permissions-issue” in the Export phase to AD. The impacted attribute in the error details will be msDs-KeyCredentialslLink.

Here’s how these errors will look like in Synchronization Service Manager (you might see multiple errors listed depending on how many users have completed provisioning Windows Hello for Business credentials):

 

hello5.png

 

After the permissions are set and at least one sync cycle has completed successfully:

  • There should be no sync errors of type “Permissions-issue” in the Export phase to on-premises AD that impact the msDs-KeyCredentialslLink attribute.


Q7: I s
tarted getting new synchronization errors after refreshing the Azure AD Connect schema and setting the permissions for the msDs-KeyCredentialslLink attribute. What else could I be missing?


Refreshing the schema in Azure AD Connect might also add additional attributes to be written back to on-premises depending on which other changes happened to the AD schema after Azure AD Connect was installed.

Two of the attributes that might be added to the outbound rules to on-premises AD are: msDS-ExternalDirectoryObjectId and publicDelegates. Both attributes are used by Exchange Online.

The error message if these permissions are not set are like the one described for msDs-KeyCredentialslLink (“Permissions-issue”), but with msDS-ExternalDirectoryObjectId and/or publicDelegates as the impacted attributes.

This issue typically happens if the AD schema was upgraded by a new version of Exchange after Azure AD Connect was installed.

 

Q8: And how do I solve these permissions errors for Exchange attributes? 

Similar to the msDs-KeyCredentialslLink attribute, make sure that the sync account(s) also has Read/Write permissions over these attributes for Descendant User Objects.

 

hello6.png

 

hello7.png

 

Q9: I’m deploying Windows Hello for Business in the key trust model, so I assumed that I don’t need any certificates, but I’m still getting errors when users try to access on-premises resources. What could be the reason?

A common misunderstanding is that the key trust model doesn’t require any certificates. Although this is true for end-users, domain controllers still need their own certificates to be able to authenticate users using Windows Hello for Business credentials.

When deploying Windows Hello for Business, make sure that:

  • Domain controllers have the proper type of certificate with the right EKU and key size.
    More information about this certificate requirements are available here.
  • The certificate chain for the on-premises PKI services is not in the local machine store.
  • The Certificate Revocation Lists (CRLs) are reachable.

Q10: Is there any additional technical information on how Windows Hello for Business provision and authentication works?

Check the deep dive documents that we have published on how Windows for Business works, including the provisioning and authentication flows.

 

For any questions, you can reach us at AskAzureADBlog@microsoft.com, Tech Communities or on Twitter @AzureAD@MarkMorow and @Alex_A_Simons. You can also ask questions in the comments of this post. Check out our previous mailbag posts!

 

- Karam Masri 

 

10 Comments
Steel Contributor

Can you help with issue of how to deal with students that don't have a verification device and how to move them to Hello for Business. More details - https://social.msdn.microsoft.com/Forums/en-US/ca83fd14-2a7b-4d8d-8636-0ed461e841a7/when-transitioni...

Copper Contributor

Are there any plans for Windows Hello on an AzureAD joined device to pass through password expiration toast notifications to the user? We are using federated accounts (adfs currently, moving to pingid) and noticed users will never get pw expiration notifications when signing in through hello.

Deleted
Not applicable

Thanks @Karam Masri, some useful snippets. 


One thing that would be good in addition is some commentary around how to measure a Windows Hello for Business rollout - i.e. how do we track:

  • How many users have created the next-gen credential?
  • How many users are authenticating with that credential
  • Failures to create the credential
  • Failures to authenticate with the credential
  • Methods used to authenticate - are users choosing to use PIN/finger/face etc?  This would be useful background for a future rollout of something like FIDO2.

Even better would be a pre-canned dashboard using log analytics data from Azure AD and on-prem DCs :)

 

Demonstrating value is difficult when we cannot measure progress and also doesn't allow us to target comms to user communities that might be struggling to register/auth for some reason.

Copper Contributor

(re-posting under the correct account - feel free to delete the duplicate comment above as it seems I can't...)

 

Thanks @Karam Masri, some useful snippets. 


One thing that would be good in addition is some commentary around how to measure a Windows Hello for Business rollout - i.e. how do we track:

  • How many users have created the next-gen credential?
  • How many users are authenticating with that credential
  • Failures to create the credential
  • Failures to authenticate with the credential
  • Methods used to authenticate - are users choosing to use PIN/finger/face etc?  This would be useful background for a future rollout of something like FIDO2.

Even better would be a pre-canned dashboard using log analytics data from Azure AD and on-prem DCs :)

 

Demonstrating value is difficult when we cannot measure progress and also doesn't allow us to target comms to user communities that might be struggling to register/auth for some reason.

Copper Contributor

Hi @Stuart Murrayand @Karam Masri,

 

did you ever find a solution for your challenge of measuring the Windows Hello for Business rollout? If so, I would be really interested how you managed to track progress of your project. At our company we have the same questions. If you have any tips, please let me know i'm really interested!

 

Kind regards,

Mark van Lierop

Copper Contributor

@AzureAD@MarkMorow @Alex_A_Simons

I am trying to implement Hybrid Key trust model but the device registration has following events.

Windows Hello for Business provisioning will not be launched.

Device is AAD joined ( AADJ or DJ++ :( Not Tested

User has logged on with AAD credentials: No

Windows Hello for Business policy is enabled: Not Tested

Windows Hello for Business post-logon provisioning is enabled: Not Tested

Local computer meets Windows hello for business hardware requirements: Not Tested

User is not connected to the machine via Remote Desk"text-autospace:none;">User certificate for on premise auth policy is enabled: Not Tested

---

Automatic device join pre-check tasks completed. Debug output:\r\n preCheckResult: Join

deviceKeysHealthy: undefined

isJoined: undefined

isDcAvailable: YES

isSystem: YES

keyProvider: undefined

keyContainer: undefined

dsrInstance: undefined

elapsedSeconds: 0

resultCode: 0x0

---

Automatic registration failed at join phase.

Exit code: Unknown HResult Error code: 0x801c001d

Server error: 

Tenant type: undefined

Registration type: undefined

Debug Output:

joinMode: Join

drsInstance: undefined

registrationType: undefined

tenantType: undefined

tenantId: undefined

configLocation: undefined

errorPhase: discover

adalCorrelationId: 73b46ec1-f877-4a3f-8d29-d5f37eed09a5

adalLog:

undefined

adalResponseCode: 0x0

----------

Copper Contributor

@Markvanlierop ,

 

I used Intune OMS and I'm capturing telemetry data which is sent to Azure. Then using PowerBI I can get this info from Azure Log Analytics and have realtime reports about Windows Hello.

Copper Contributor

Regarding this part of the blog post:

 

When deploying Windows Hello for Business, make sure that:
Domain controllers have the proper type of certificate with the right EKU and key size.
More information about this certificate requirements are available
 here.
The certificate chain for the on-premises PKI services is not in the local machine store.
The Certificate Revocation Lists (CRLs) are reachable.

Is that bolded line above correct? The chain should not be in the local machine store?

 

Copper Contributor

Hi There,


We don't have WHfB enabled in our environment and yet we have about 10% of our users with key information in the msDs-KeyCredentialslLink attribute on-prem. I can see from looking at Azure AD the attribute is definitely being synced down from the "searchableDeviceKey" AAD attribute but why is it being populated in the first place if we aren't using WHfB?

Cheers

C

Copper Contributor

This article saved me! I had the permissions to the new attributes set correctly at the domain, but because some users are in Protected Groups and inheritance was disabled on their accounts, in some cases they didn't even have the msol account on the security tab! Might be worth mentioning to check the security permissions for the individual user.

My answer was just to use a script to enable inheritance on all users in the OU again and if it drops it that's ok because it should keep the ones it inherited that one time. Ideally, I should remove them from the groups, but enabling it so it could sync was faster haha.

Version history
Last update:
‎Jul 24 2020 01:39 AM
Updated by: