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.
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).
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.
Scroll down on the permissions list to make sure that the account is granted read and write permissions over the msDS-KeyCredentialLink attribute:
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):
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 started 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.
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