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?
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:
Q2: Which of the steps that are commonly missed cause these symptoms?
There are several possible causes for these symptoms:
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:
After the Azure AD Connect schema is refreshed and at least one sync cycle has completed successfully:
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:
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:
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:
Q10: Is there any additional technical information on how Windows Hello for Business provision and authentication works?
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.