Windows Hello – it was working until November 2016?
If like me you’ve been using Windows Hello on your devices that are domain joined quite happily up until the November patch Tuesday, then all hell broke loose as Windows Hello was updated – however MS didn’t mention this, or at least I didn’t see anything. The net result was that domain joined PCs/devices that were using Hello (either PIN or biometric) stopped working and users had to go back to passwords to login…how last year! The KB is question that appears to have made the change was KB3199986.
At best you would have seen an error message like this:
At worse you’ll see something along the lines of “no logon servers were available to service your request”. If you are seeing either of these errors then the following will help you get this resolved.
So this KB update and consequential change sent me in to the wild world of Hello for Business (aka Windows Passport) which was a new world for me. Ok the basics are wrapped up in Windows authentication and Active Directory so it shouldn’t be that complicated, can it? Well the first thing every IT Pro will know is that when our friends at Redmond release a new product or an update the documentation on the various Microsoft sites can be, let’s say, lacking. This is the case with the documentation relating to configuring Windows Hello for Business. There are a couple of different ways to implement Hello for Business, these are certificate based and key based. The certificate based method requires a lot more investment in infrastructure services, if you don’t have them already i.e. SCCM, KPI servers etc. Give Microsoft credit they have realised that some customers don’t want to go down this route/cost. This is where the key based model comes in, however there is LOTs of information out there for building certificate based solutions but I couldn’t find anything for key based. The Microsoft documentation does pay lip-service to it but it lacks the guts that us IT pro’s need to get the ball rolling.
Windows Hello for Business – Prerequisites
So before we can get started implementing Windows Hello for Business we need to make sure that we have the parts in place to support it. Checking out the documentation on TechNet they helpfully provide a list of the components that we need here.
So the ingredients for Windows Hello for Business key based authentication are:
- Active Directory (on-premise)
- Azure Active Directory subscription
- Windows Server 2016 Domain Controller
- Azure AD Connect (AD sync from on-premise to Azure AD)
- Active Directory Group Policy (on-premise)
- Active Directory Certificate Services
There is lots of information out there that seems to suggest you need additional ingredients to get key based authentication for Windows Hello for Business working however the above list is all you need…trust me 🙂
My current environment – Windows Server 2012R2 Active Directory
So lets start with my current environment configuration, it is most likely very similar to yours in that I have a on-premise Active directory which is running Windows Server 2012R2 and schema. I have Azure AD connect running on one of my DCs that is syncing to Azure AD, which is also the AAD that is servicing my Office 365 tenant. I do have Intune enabled on this tenant but I can assure you now that is isn’t a pre-req for Windows Hello for Business key based authentication.
The PCs are currently using Windows Hello PIN and biometrics to authenticate – this is pre KB3199986. Everything at this stage is working fine…then KB3199986 lands and this triggers Windows Hello for Business which means that the current infrastructure will need to support this if the users are to continue using PINs and biometrics.
Windows Hello for Business – Windows Server 2016 Install
This first thing we need to do is install a Windows Server 2016 server. This is the only bit of new “stuff” you need to purchase for your infrastructure to support Windows Hello for Business. Assuming that you’ve purchased your license for Windows Server 2016 you can start.
Install Windows Server 2016 – I am not going to go through the process of installing Windows Server as I am sure you all know how to do that, and lets face it these days it is soo simple anyone can do it 🙂
First off, complete the following tasks:
- Install Windows Server 2016
- Install “Active Directory Domain services” feature
The next step is to promote this server to a domain controller within your existing domain. Now be aware that this process will update your Active Directory schema to 2016 (version 87), you can see your schema version by opening up ADSI edit, connecting to the schema, opening properties and locate objectVerison.
If you have services that are reliant on a version of AD schema to be present you may want to stop now and consult with your peers to determine the effect of a schema change on your organisation.
Assuming you’re happy to continue you can carry on and promote your new Windows Server 2016 to a Domain Controller. Again I am going to assume you know how to do this. Once the promotion has completed you can view the schema version in ADSI edit to confirm that everything was successful.
Windows Hello for Business – Install Active Directory Certificate Services feature
The next step is to install ADCS onto a server within your infrastructure. If you’ve already got this installed on your infrastructure you can skip this step. If you’re still with me then we’ll continue. In my case I didn’t have a ADCS service present on my infrastructure and as the ultimate goal will be to decommission my 2012R2 servers I decided to install ADCS onto my 2016 server.
From Server Manager select “Manage” -> “Add roles and features”
Select “Role-based or feature based installation”
Select the server you want to install ADCS onto from the list
Select “Active Directory Certificate Services”
Click on “Add Features”
Click “Next”
Click “Next” on the “Select Features” screen
Click “Next”
Ensure that only “Certificate Authority” is selected then click “Next”
Finally click on “Install”
Once installed click on “Close”
Windows Hello for Business – Configure Active Directory Certificate Services
From the server manager click on the notification flag and then click “Configure Active Directory Certificate Services on the..”
Enter the credentials of a user that is a member of the Enterprise Admins group
Select “Certification Authority” and click “Next”
Select “Enterprise CA” and click “Next”
Select “Root CA” and click “Next”
Select “Create a private key” and click “Next”
Check the defaults are set as shown and then click “Next”
You can take the defaults on this page, it will use the DC name and domain to construct the name, click “Next”
Set the expiry date and click “Next”
Set the database locations, in my case I’ve got my AD databases on a different drive so I’ve located the CA databases in the same drive, click “Next”
Finally check that the details provided in the confirmation window and click “Configure”
Hopefully after a few seconds you’ll see confirmation that everything went to plan, click “Close”
Windows Hello for Business – Setup Kerberos Authentication Root Certificate
Ok, so far we’ve installed a Windows 2016 server, added this to the 2012R2 active directory as a domain controller. Installed Active Directory Certificate Services on this server and configured it to be enterprise CA. The next step is to create the Kerberos Authentication certificate for the domain controllers. This is needed by Windows Hello for Business so it can authenticate the domain controllers, with out this Hello won’t authenticate on the local active directory.
Open MMC (Microsoft Management Console) and click on “File” -> “Add/Remove Snap-in..”
Select “Certificates” and click “Add”
Select “Computer Account” and click “Next”
Select “Local computer” and click “Finish”
Expand “Certificates” -> Expand “Personal” -> Expand “Certificates”. Click on “All tasks” -> “Request New Certificate”
Click on “Next” at “Before you begin” screen
The option should already be set to “Active Directory Enrollment Policy”, click “Next”
Check “Kerberos Authentication” and click “Enroll”
After a few moments you should get a “Succeeded” screen, click “Finish”
VERY IMPORTANT! You MUST create this certificate on every domain controller in your forest.
Windows Hello for Business – Azure AD Connect Re-sync
The good news is that we are almost there!! One last piece of the puzzle that without it you’ll never get Windows Hello for Business working properly, I know this because this one piece took me 3 days to discover….the good news is I won’t need a haircut for a while as I’ve pulled it all out!
The missing bit…..Azure AD connect! Now if you’re like me you’ve had this little product running happily in your current environment for some time, and because it take very little maintenance it can be overlooked when making changes the infrastructure. And what change have we recently made……we’ve updated the Active Directory schema will all sorts of goodies from Windows Server 2016 to support our new life on the cloud. However good old AD Connect has no idea we’ve done this so its happily syncing the stuff it knows about, which is where the problem lies. The extra attributes within the new schema are essential to getting Windows Hello for Business to work so we need to update AD Connect to replicate the new schema to AzureAD. The great news here is that is a pretty simple process, thank you Microsoft!
From the server that is currently running AD Connect double click on the application icon
Select “Refresh Directory Schema” and click “Next”
Enter the credentials of a global admin on your Azure AD, best practice is to use the same account that was used when the AD Connect was initially installed. Click “Next”
Select the domain you’d like to refresh and click “Next”
Check the “Start the synchronisation process when configuration completes” and click “Configure”
After a few minutes (depending on the size of your organisation) you’ll see the success page.
Windows Hello for Business – Group Policy Configuration
The last step is to configure Group Policy to enable Windows Hello for Business
Download the latest Windows 10 ADMX files from Microsoft here and update either your DCs or central store.
Once installed you can find the Windows Hello for Business GPO in:
Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Hello for Business.
The main option here is “Use Windows Hello for Business” and this needs to be set to “Enabled”
That’s it for the infrastructure side of things, you’re now ready to support Windows Hello for Business.
Windows Hello for Business – Client Configuration
Client configuration is a bit tricky because they could be at different stages. For example my users saw the following screen when they restated their PCs after the update was applied.
I am assuming this screen was shown because they had already had PIN/biometrics configured and Windows assumed that there was already a Windows Hello for Business infrastructure installed, which there wasn’t of course. In most cases the users have gone through the PIN wizard that follows the above screen and then discovered that the PIN/biometrics no longer work and have reverted back to passwords. However as soon as the infrastructure was is in place they will be able to start using their PIN/biometrics again with no additional configuration.
I did have a couple of test environments running when I was writing this blog, on one of the domains I couldn’t get the PIN/biometrics to work at all. I kept hitting strange errors when using the PIN like this:
There were a couple of differences between this domain and the domain that was working. These were this was connected to a Business Premium Office 365 tenant vs the working tenant which was a E3 tenant with AD Premium enabled. The other difference was this domain had a domain controller which was on an Evaluation license. The working domain all the DCs were using fully licensed servers. Once I removed the server running the evaluation license from the domain Windows Hello for Business started working properly. Now I don’t know if the issue was the eval license, maybe removing it from the domain changed something. The DC with the eval license was also running AD connect so I moved this to the Server 2016 DC. Again this action might have been what caused Windows Hello for Business to kick into life, I’m not sure. But I though it would be worth me nothing these experiences just in case it helps someone else in the future.
Nice article, thanx for wrapping this up. Saved us a lot of time. Can’t really
Pingback: Windows 10 - Hello for Business - Return of the "That option is temporarily unavailable" message - IT Geek Rambling
Thanks for the posting. I met the same issue you mentioned “one of the domains I couldn’t get the PIN/biometrics to work at all”. Did you find the root cause finally?
I didn’t spend any more time on that issue, however I have discovered that if you are getting similar error messages to those shown in this post they are normally related to a disconnect between AzureAD and local AD. First point of call is check for errors in FIM and also ensure that the devices are registered in AzureAD.
very good article !
I’ve a question, is it possible to use Hello for business without AzureAD ?
It’s very unclear for me
Thanks.
Currently it’s baked into AAD and cannot be provisioned with out AAD. I believe this might change in the future if the demand is there.
Quick update, Windows Hello for Business is now supported with just a on-premise Active Directory infrastructure. However it is only supported with Windows 10 1703 (Creators Update). More info here – https://technet.microsoft.com/en-gb/itpro/windows/keep-secure/hello-manage-in-organization and does require ADFS and Windows Server 2016
How do I create this certificate on every domain controller in my forest. export and import ?
No, you just need to run through the “Setup Kerberos Authentication Root Certificate” process on each DC
I have the same question. You say that you need to run through the “Setup Kerberos Authentication Root Certificate” process on each DC. But the other DCs don’t allow you to do this. Either it gives an error after clicking on Next at the “Select Certificate Enrollment Policy” or it says that there are no certificate types available.
Do you need to create a certificate authority on each DC? If not, how do you create a certificate on each DC?
Hi, if you’re getting an error at this stage that suggests there is either an issue with the CA for the domain or there is something wrong with the replication between the DCs.
I have the same problem. It won’t let me do this on the other DCs. Can you elaborate?
Hi Rob,
Great article thanks, have follow the steps and so far so good. Windows Hello for Business is very confusing in MS documentation.
Do you know/can you confirm if you need to sync windows 10 domain joined devices to AAD for this to work or is the AD user in AAD that WHfB uses? Currently we only sync AD Users/Passwords to AAD and got a message about running a prep script for this but it may be generic.
Also do you know what role AAD plays in managing WHfB as a bit of background (in plain English) would be great.
Thanks
Ross
If you’re using an environment that is consuming AAD then the devices do need to be registered in AAD. Simple to do, some quick PowerShell and a single GPO will sort it.
Hi,
2nd Question, do you know if we can force bio-metrics to be used as that is what we’d like to implement? We’d like to move away from staff saying colleague/family had their password/pin and used the laptop and force them to be present with face/fingerprint for login. I have been searching on this but can’t find a solution.
The Group policy option ‘Use biometrics’ says if Enabled: Biometrics can be used as a gesture in place of a PIN.
Not that biometrics MUST be used along with a pin.
Cheers,
Ross
Ross
As I understand it you still need a “backup” to biometrics, beyond using Intune or GPO to manage the way that biometrics/PINs are enforced I can’t offer anymore help. However I do recommend having a read of Jairo Cadena’s blog here https://jairocadena.com/ as he is the expert with Windows Hello and I’m sure he’ll be able to help.
Hi Rob,
Thanks for your blog post. It is very appreciated. One peice i’m trying to uncover is the need for 2016 DCs. I see this on MS Docs:
The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Windows Hello IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 domain controllers required.
This is very vague in regards to a larger environment. Is sites and services in play here? do we need at least one 2016 DC per AD site to service these login requests? Any information would be appreciated.
Thanks,
LvilleSystemsJockey
Hi
The 2016 DC updates the existing schema to 2016 which allows support for Windows Hello
Rob
Great post! I need to understand the correct way to implement Windows Hello for bussines.
Does this now require Azure MFA? I was wondering if you could provide some insight into the latest documentation here: https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-identity-verification#prerequisites
Interesting document, it does seem to suggest MFA is required and to be honest I’ve only ever set it up with MFA enabled tenant (Office 365).
Thanks. Is there a cost with enabling MFA for Office 365? Do you know the steps to take to do this?
No cost, it’s included in the Office 365 subscription. To access it go to the Office 365 admin portal -> Services -> Services & Add ins -> Azure multi-factor authentication. More info here
I really appreciate your help. It’s a shame Microsoft isn’t this helpful.
One more quick question… Are the group policies to enable Windows Hello applied to a user or computer? I know Windows Hello is per device, but I’m trying to figure out if we can just turn it on for certain user accounts. Thanks again.
No problem, it can sometimes be tricky to find the right people at MS to answer your questions, sometimes you can be lucky. In answer to your question the GPO is applied to the Computer object.
Hello,
I have set up Windows Hello For Business via Hybrid Certificate-trust; two users are able to enroll but cannot sign in with the PIN created. Every time they try to sign in, they get error message “that option is temporarily unavailable for now”. What could be wrong???
Also, not all enabled Windows Hello for Business users can enroll, as the provisioning screen would not pop up but the systems&users are AAD joined. What could be wrong???
Hi,
Take a look at my other post HERE to help you troubleshoot the issue. The issue will most likely be around your on-prem AD and not being able to communicate with AAD.
Hello Rob,
Thanks for the reply. But there are no export errors in AAD as at 10/20/2017 12.52.27PM (GMT+1)
Everything appears fine from AAD and AD. Or, does this depend on the number of 2016 DCs on prem?
Also, I noticed the users unable to enrol have NGC:NO on their PCs. Is there a way to force NGC:YES?
Those errors are caused by a sync issue between the on-prem AD and AAD. Have you run the AD Connect wizard since adding the 2016 DC to the domain. It might be some of the schema updates haven’t been replicated properly.
Hello Rob,
Thanks for the reply…
I refreshed the schema yesterday, the ms-KeyCredentialLink is updated but WHfB is not launched yet. Please, what else would I be checking for?
After running schema update, the initial two clients (1607) are unable to sign on with WHfB: error message is “This request is not supported”; I want to assume it’s because the client machines do not have Creator’s Update (1703). However, for other systems with Creator’s update, WHfB is still not launched.
Also, is there need to deploy NDES server alongside the Enterprise CA for Hybrid authentication? I must have missed that out from onset.
Awaiting your response…
There is no requirement for NDES. Can you check that you’ve deployed the Kerberos authentication certificate to ALL domain controllers. Also check that the devices have registered in AAD, this is done via GPO. Use the dsregcmd.exe /status command to get more detail on the status of the PC, under AzureADJoined it should be “Yes”. You can also use PowerShell cmdlet Get-MsolDevice to confirm if a device is registered in AAD.
Hello Rob,
Thanks for the NDES clarification; Kerberos authentication has been deployed to all Domain Controllers; all test devices are registered in AAD, AzureADJoined is YES. The registered devices are visible in Azure Active Directory as Hybrid joined….
What else do you think is outstanding?
I can’t think of anything else that might be a miss, maybe another view point might help. Have you tried Jairo Cadena’s blog here https://jairocadena.com/ he is part of the AzureAD team and is worth reaching out to.
Hello Rob,
Thanks. I have also upgraded the AD-Connect to 1.1.649. No errors on the synchronization service. Yet, PIN logon gives “The request is not supported”.
I’m so so worried, what could be missing!
Was everything working before upgrading AD Connect?
Great article Rob! Saved me a lot of time trying to decipher what the requirements where from MS website.
So grateful for this article.
I’d set it all up OK but couldn’t get it going. Kept pouring through the documentation, but if it’s in there I missed it:
ADConnect schema refresh!
Great article thanks.
I am having an issue, if i logon with either a pin or hardware key when i try and access shares on say my DC i get an auth prompt which fails if i try and use pin and never even shows option for hardware key or biometrics,
If i logon with AAD username and password to the win 10 machine it auths just fine.
also in eventviewr i see this, but all the pictures in MS docs for key trust indicate these should be set to something. any ideas?
User certificate for on premise auth policy is enabled: No
Machine is governed by none policy.