Windows 10 – Windows Hello for Business – Key based configuration

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:Hello for Business - That option is temporarily unavailable

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.

Windows Hello for Business - Current Active Directory Configuration

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.

Active Directory Schema Level

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”

Install Active Directory Certificate Services

Select the server you want to install ADCS onto from the list

Install Active Directory Certificate Services

Select “Active Directory Certificate Services”

Install Active Directory Certificate Services

Click on “Add Features”

Install Active Directory Certificate Services

Click “Next”

Install Active Directory Certificate Services

Click “Next” on the “Select Features” screen

Install Active Directory Certificate Services

Click “Next”

Install Active Directory Certificate Services

Ensure that only “Certificate Authority” is selected then click “Next”

Install Active Directory Certificate Services

Finally click on “Install”

Install Active Directory Certificate Services

Once installed click on “Close”

Install Active Directory Certificate Services

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

Install Active Directory Certificate Services

Enter the credentials of a user that is a member of the Enterprise Admins group

Configure Active Directory Certificate Services

Select “Certification Authority” and click “Next”

Configure Active Directory Certificate Services

Select “Enterprise CA” and click “Next”

Configure Active Directory Certificate Services

Select “Root CA” and click “Next”

Configure Active Directory Certificate Services

Select “Create a private key” and click “Next”

Configure Active Directory Certificate Services

Check the defaults are set as shown and then click “Next”

Configure Active Directory Certificate Services

You can take the defaults on this page, it will use the DC name and domain to construct the name, click “Next”

Configure Active Directory Certificate Services

Set the expiry date and click “Next”

Configure Active Directory Certificate Services

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”

Configure Active Directory Certificate Services

Finally check that the details provided in the confirmation window and click “Configure”

Configure Active Directory Certificate Services

Hopefully after a few seconds you’ll see confirmation that everything went to plan, click “Close”

Configure Active Directory Certificate Services

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”

Create Kerberos domain authentication root certificate - Windows Hello for Business

Select “Computer Account” and click “Next”

Create Kerberos domain authentication root certificate - Windows Hello for Business

Select “Local computer” and click “Finish”

Create Kerberos domain authentication root certificate - Windows Hello for Business

Expand “Certificates” -> Expand “Personal” -> Expand “Certificates”.  Click on “All tasks” -> “Request New Certificate”

Create Kerberos domain authentication root certificate - Windows Hello for Business

Click on “Next” at “Before you begin” screen

Create Kerberos domain authentication root certificate - Windows Hello for Business

The option should already be set to “Active Directory Enrollment Policy”, click “Next”

Create Kerberos domain authentication root certificate - Windows Hello for Business

Check “Kerberos Authentication” and click “Enroll”

Create Kerberos domain authentication root certificate - Windows Hello for Business

After a few moments you should get a “Succeeded” screen, click “Finish”

Create Kerberos domain authentication root certificate - Windows Hello for Business

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”

Azure AD Connect - Refresh the directory schema

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”

Azure AD Connect - Refresh the directory schema

Select the domain you’d like to refresh and click “Next”

Azure AD Connect - Refresh the directory schema

Check the “Start the synchronisation process when configuration completes” and click “Configure”

Azure AD Connect - Refresh the directory schema

After a few minutes (depending on the size of your organisation) you’ll see the success page.

Azure AD Connect - Refresh the directory schema

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”

Windows Hello for Business Group Policy Object

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.

Windows Hello for Business - Windows client configuration

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:

Windows Hello for Business - The request is not supported

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.

32 thoughts on “Windows 10 – Windows Hello for Business – Key based configuration

  1. Thorwald

    Nice article, thanx for wrapping this up. Saved us a lot of time. Can’t really

    Reply
  2. Pingback: Windows 10 - Hello for Business - Return of the "That option is temporarily unavailable" message - IT Geek Rambling

  3. Yizhong

    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?

    Reply
    1. Rob Post author

      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.

      Reply
  4. Anthony

    very good article !
    I’ve a question, is it possible to use Hello for business without AzureAD ?
    It’s very unclear for me

    Reply
    1. Rob Post author

      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.

      Reply
  5. dinesj

    How do I create this certificate on every domain controller in my forest. export and import ?

    Reply
    1. Rob Post author

      No, you just need to run through the “Setup Kerberos Authentication Root Certificate” process on each DC

      Reply
  6. Ross

    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

    Reply
    1. Rob Post author

      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.

      Reply
  7. Ross

    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

    Reply
    1. Rob Post author

      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.

      Reply
  8. LvilleSystemsJockey

    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

    Reply
    1. Rob Post author

      Hi

      The 2016 DC updates the existing schema to 2016 which allows support for Windows Hello

      Rob

      Reply
    1. Rob Post author

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

      Reply
      1. Ryan

        Thanks. Is there a cost with enabling MFA for Office 365? Do you know the steps to take to do this?

        Reply
        1. Rob Post author

          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

          Reply
          1. Ryan

            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.

          2. Rob Post author

            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.

  9. Mayok

    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???

    Reply
    1. Rob Post author

      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.

      Reply
  10. Mayok

    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?

    Reply
    1. Rob Post author

      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.

      Reply
  11. Mayok

    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…

    Reply
    1. Rob Post author

      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.

      Reply
  12. Mayok

    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?

    Reply
    1. Rob Post author

      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.

      Reply
  13. Mayok

    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!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *